Migrating a web hosting service from a shared environment for multiple clients to a shared environment for multiple clients

ABSTRACT

An automated tool for migrating a website hosting service from a first website hosting architecture to a second website hosting architecture, each website hosting architecture comprising a server architecture that serves a plurality of common services from a plurality of machines to a plurality of unrelated websites.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/007,157 filed Jan. 14, 2011 which is incorporated by reference in itsentirety and which claims the benefit of the following provisionalapplications, each of which is hereby incorporated by reference in itsentirety: U.S. Ser. No. 61/295,506 filed Jan. 15, 2010; U.S. Ser. No.61/295,528 filed Jan. 15, 2010; U.S. Ser. No. 61/303,281 filed Feb. 10,2010; U.S. Ser. No. 61/345,568 filed May 17, 2010; and U.S. Ser. No.61/376,743 filed Aug. 25, 2010.

BACKGROUND OF THE INVENTION

1. Field

The inventive methods and systems described herein generally relate tointernet web hosting and particularly relate to web hosting based on aservice pool-based architecture.

2. Description of the Related Art

Web hosts or web hosting systems are companies that provide space on aserver they own or lease for use by their clients as well as providingInternet connectivity, typically in a data center. Web hosts can alsoprovide data center space and connectivity to the Internet for serversthey do not own to be located in their data center. The web hostingsystems are based on special software and hardware technologies. Serverscan be divided into several independent virtual hosts. With all theinternet server features, each host may include an independent domainname. Different user programs may run without interference on samehardware and operating system. Further, every user may own personalsystem resources like storage capacity, memory, CPU time, and the like.This may save a lot of cost of host service. The web hosting system mayprovide a user control panel for controlling domain name, websitecapacity, file system, database, storage capacity, and the like.

Further, a web hosting system may provide a wide range of e-commerce,application hosting, and connectivity services. Such services are knownas web hosting services. A web hosting service is a type of Internethosting service that allows individuals and organizations to make theirown website accessible via the World Wide Web. For example, a company orindividual may contract with a web hosting company to provide aspecified amount of memory on a server for the company to establish andmaintain its web site. In addition, the web hosting system may contractfor other types of services, such as, for example, email services,secure socket layer (SSL), file transfer protocol (FTP) service,database services, and real media service allowing streaming audio andvideo from the company's web site.

Web hosting technology and services has evolved over time, withincremental advances based primarily on improved system performanceimprovements and virtualization. However, a comprehensive approach toproviding the computing, data, and customer services for web hostingthat enhances client retention, new client sales, industryconsolidation, and supports significant scalability capabilities whileensuring broadly diverse marketing and operation optimization has yet tobe undertaken in a novel way.

SUMMARY OF THE INVENTION

In an aspect of the invention, methods and systems may include aservices oriented web hosting architecture that may include arrangingweb servers into service-specific groups with access to common datastorage; establishing a service-specific group for each of several webservices being provided to web hosting customers; and matching a webservice request to a service-specific group and forwarding the requestto a server that is most capable of providing a rapid response from theservers in the service-specific group. In the aspect, a web servicerequest is provided by a load balancing server. In the aspect,forwarding the request to a server includes load balancing among theservers in the matched service-specific group to determine the mostcapable server. In the aspect, forwarding the request is provided by aload balancing server.

In the aspect each server in a service-specific group is programmed toprovide a service that is only provided by servers in theservice-specific group. Also, providing a rapid response in the aspectincludes accessing the common data storage to retrieve or depositcontent identified by the web service request.

In another aspect of the invention, a services oriented web hostingarchitecture includes a plurality of web servers arranged intoservice-specific groups with access to common data storage, wherein eachservice-specific group is dedicated to one of several web services beingprovided to web hosting customers; and a load balancing server formatching a web service request to a service-specific group and forforwarding the request to a server in the service-specific group that ismost capable of providing a rapid response. In the aspect, the loadbalancing server is also for load balancing among the servers in thematched service-specific group to determine the most capable server.Also, in the aspect each server in a service-specific group isprogrammed to provide a service that is only provided by servers in theservice-specific group. In the aspect, any of the plurality of webservers accesses the common data storage to retrieve or deposit contentidentified by the web service request.

The new web hosting architecture may be associated with an unaffiliatedweb domain hosting service based on a common service architecture. In anaspect of the invention, a website hosting service may provide aplurality of services from a common service architecture to each of aplurality of [unrelated/unaffiliated] websites. The common servicearchitecture may be adapted to provide a different package of servicesto at least a plurality of unrelated websites.

The new web hosting architecture may be associated with an unaffiliatedweb domain hosting service based on common service pools architecture.Further, a website hosting architecture may provide a plurality ofservices, from a plurality of service pools, to each of a plurality of[unrelated/unaffiliated] websites. The each of the plurality of servicepools may be adapted to provide services that may be adapted to becombined into different packages to be delivered to at least a pluralityof the [unrelated/unaffiliated] websites.

The new web hosting architecture may be associated with an unaffiliatedweb domain hosting service based on shared data structure. In anotheraspect of the invention, a website hosting architecture may provide aplurality of services to each of a plurality of [unrelated/unaffiliated]websites. Any one of the plurality of services may be configured to bedeployed to serve any one of the plurality of unrelated websites.Further, the deployed service may extract data from a shared datastructure that may maintain data for at least a plurality of the[unrelated/unaffiliated] websites.

The new web hosting architecture may be associated with an unaffiliatedweb domain hosting service based on service pools with flexibleresources. In yet another aspect of the present invention, the websitehosting architecture may provide a plurality of services, from aplurality of service pools, to each of a plurality of[unrelated/unaffiliated] websites. The each of the plurality of servicepools may be adapted to contribute services to distinct service packagesfor at least a plurality of [unrelated/unaffiliated] websites. Further,the each of the plurality of service pools distributed across aplurality of servers, each server may be adapted to provide anoverlapping service set in order to facilitate flexible resources fromeach of the plurality of service pools. Furthermore, the each server maybe a virtualized server. Additionally, the each server may be a physicalserver.

The new web hosting architecture may be associated with a commonservices web hosting architecture with multiple branding. In stillanother aspect of the present invention, the website hosting service mayprovide a plurality of services, from a common service architecture, toeach of a plurality of [unrelated/unaffiliated] websites. The each ofthe plurality of services may be adapted to contribute to a distinctpackage of services for at least a plurality of [unrelated/unaffiliated]websites. Further, the web hosting service may be marketed through aplurality of websites, at least a plurality of sites that may describedifferent market specific offerings for the packages of services.

The market specific offerings may include different brands for theofferings, different messages for the offerings, different service termsand conditions for the offerings, different pricing structures for theofferings, and the like.

The new web hosting architecture may be associated with a commonservices web hosting architecture with multiple branding and OSSconsistency. In an aspect of the invention, the website hosting servicemay provide a plurality of services, from a common service architecture,to each of a plurality of unrelated websites. The each of the pluralityof services may be adapted to contribute to a distinct service packagefor at least a plurality of [unrelated/unaffiliated] websites. Further,the web hosting service may be marketed through a plurality of websites.Each one of the plurality of sites may offer a different market specificoffering and each market specific offering may be maintained under aconsistent look and feel associated with the market specific offeringwhen presenting account service user interfaces.

The market specific offerings may include different brands for theofferings, different messages for the offerings, different service termsand conditions for the offerings, different pricing structures for theofferings, and the like.

The new web hosting architecture may be associated with a web hostingservice based on a common service architecture and third party services.In an aspect of the present invention, the website hosting service mayprovide a plurality of services to each of a plurality of unrelatedwebsites each of the plurality of services may be adapted to contributeto a distinct service package for at least a plurality of[unrelated/unaffiliated] websites. Further, at least one of theplurality of services serving a third party[interface/API/plug-in/service] may allow a third party to access thedistinct service package. The third party may experience informationconsistent with a market specific service offering.

The new web hosting architecture may be associated with migration of aweb hosting service from one architecture to another, where at least oneis a service pool architecture. In an aspect of the invention, anautomated tool for migration of a website hosting service from a firstwebsite hosting architecture to a second website hosting architecturemay be provided. The first architecture may include a serverarchitecture that may serve a plurality of services dedicatedexclusively to a specific website. The second web hosting architecturemay include a server architecture that may serve a plurality of commonservices to a plurality of [unrelated/unaffiliated] websites.

The new web hosting architecture may be associated with migration of aweb hosting service from one box per customer architecture to a multiplebox per customer architecture. In another aspect of the invention, anautomated tool for migration of a website hosting service from a firstwebsite hosting architecture to a second website hosting architecturemay be provided. The first architecture may include a serverarchitecture that may serve the services necessary for a specificwebsite from a single machine. The second web hosting architecture mayinclude a server architecture that may serve a plurality of commonservices from a plurality of machines to a plurality of[unrelated/unaffiliated] websites.

The new web hosting architecture may be associated with migrating a webhosting service from a one box per customer architecture to a cloudcomputing architecture. In yet another aspect of the invention, anautomated tool for migration of a website hosting service from a firstwebsite hosting architecture to a second website hosting architecturemay be provided. The first architecture may include a serverarchitecture that may serve the services necessary for a specificwebsite from a dedicated machine. The second web hosting architecturemay include a server architecture that may serve a plurality of commonservices from a plurality of machines to a plurality of[unrelated/unaffiliated] websites using a cloud computing architecture.Further, the dedicated machine of the first website hosting architecturemay have one or more substantially duplicate machines for backuppurposes.

The new web hosting architecture may be associated with migration of aweb hosting service from a one box per customer architecture to a gridcomputing architecture. In still another aspect of the presentinvention, an automated tool for migration of a website hosting servicefrom a first website hosting architecture to a second website hostingarchitecture may be provided. The first architecture may include aserver architecture that may serve the services necessary for a specificwebsite from a dedicated machine. The second web hosting architecturemay include a server architecture that may serve a plurality of commonservices from a plurality of machines to a plurality of[unrelated/unaffiliated] websites using a grid computing architecture.Further, the dedicated machine of the first website hosting architecturemay have one or more substantially duplicate machines for backuppurposes.

The new web hosting architecture may be associated with migration of aweb hosting service from a one box per multiple customer architecture toa cloud or grid computing architecture with many boxes for manycustomers. In yet another aspect of the present invention, an automatedtool for migration of a website hosting service from a first websitehosting architecture to a second website hosting architecture may beprovided. The first architecture comprising a server architecture thatmay serve the services necessary for a plurality of distinct websitesfrom a dedicated machine. The second web hosting architecture mayinclude a server architecture that may serve a plurality of commonservices from a plurality of machines to a plurality of[unrelated/unaffiliated] websites using at least one of a cloudcomputing architecture and a grid computing architecture. Further, thededicated machine of the first website hosting architecture may have oneor more substantially duplicate machines for backup purposes.

The new web hosting architecture may be associated with migration of aweb hosting service from a dedicated environment for each customer to ashared environment for multiple customers. In still another aspect ofthe present invention, an automated tool for migration of a websitehosting service from a first website hosting architecture to a secondwebsite hosting architecture may be provided. The first architecture mayinclude a server architecture that may serve the services necessary fora customer's websites from a dedicated machine. The second web hostingarchitecture may include a server architecture that may serve aplurality of [unrelated/unaffiliated] customers from a plurality ofshared servers.

In an embodiment of present invention, the first web hostingarchitecture may include dedicated memory for each customer. Further,the second web hosting architecture may include shared memory acrossmultiple customers. The second web hosting architecture may be a cloudcomputing environment, a grid computing environment, and the like.Furthermore, the second web hosting architecture may include a pluralityof common service pools disposed across a plurality of servers.

The new web hosting architecture may be associated with migration of aweb hosting service from a dedicated environment for each customer to ashared environment for multiple customers. In an aspect of the presentinvention, an automated tool for migration of a website hosting servicefrom a first website hosting architecture to a second website hostingarchitecture may be provided. Each website hosting architecture mayinclude a server architecture that may serve a plurality of commonservices from a plurality of machines to a plurality of[unrelated/unaffiliated] websites.

In the aspect, at least one environment may be a cloud computingenvironment, a grid computing environment, and the like. Further, the atleast one environment may include a plurality of common service poolsdisposed across a plurality of servers.

The new web hosting architecture may be associated with migration of aweb hosting service from a virtualized environment to a sharedenvironment for multiple customers. In another aspect of the presentinvention, an automated tool for migration of a website hosting servicefrom a first website hosting architecture to a second website hostingarchitecture may be provided. The first architecture may include avirtualized server architecture that may serve the services necessaryfor a customer's websites from a specific virtual machine. The secondweb hosting architecture may include a server architecture that mayserve a plurality of [unrelated/unaffiliated] customers from a pluralityof shared servers.

In the aspect, the shared environment may be a cloud computingenvironment, a grid computing environment, and the like. Further, theshared environment may include a plurality of common service poolsdisposed across a plurality of servers.

The new web hosting architecture may be associated with migration of aweb hosting service from one architecture to another, wherein a virtualnetwork is used during migration. In an aspect of the present invention,an automated tool for migration of a website hosting service from afirst website hosting architecture to a second website hostingarchitecture may be provided. A Virtual Network may be used duringmigration that may facilitate keeping the network active during themovement of IP addresses from one architecture to the otherarchitecture.

The new web hosting architecture may be associated with an unaffiliatedweb domain common hosting service with service representative plug-ins.In yet another aspect of the present invention, a website hostingservice that may provide a plurality of services, from a common servicearchitecture, to each of a plurality of unrelated websites may beprovided. The each of the plurality of services may be adapted tocontribute to a distinct service package for at least a plurality of[unrelated/unaffiliated] websites. The web hosting service may bemarketed through a plurality of websites. The each one of the pluralityof websites may offer a different market specific offering. The servicerepresentatives supporting a plurality of different market specificofferings may be provided with information that may facilitate providingthe appropriate service for a particular market specific offering.

In an embodiment, a method of website hosting is provided. The methodmay include serving a plurality of website hosting services. One of theplurality of website hosting services may be adapted to meet a websiteservice requirement of each of a plurality of unrelated websites.Further, the one of the plurality of website hosting services may beadapted differently for each of a plurality of different servicepackages. The plurality of different service packages may include afirst package of services for a first website and a second package ofservices for a second website. The first service package of theplurality of different service packages may be provided to a pluralityof related websites. The related websites may share a common clientwebsite hosting subscriber. Further, the first service package of theplurality of different service packages may be provided to at least onewebsite that may be unaffiliated with the plurality of related websites.The first website and second website may be unrelated websites. At leasttwo of the plurality of website hosting services may be served fromdifferent servers. Further, the plurality of website hosting servicesmay be common services provided by a common service architecture. In theembodiment, the common service architecture may include a cloudcomputing based server architecture, a grid computing based serverarchitecture, and the like. The method may adapt one or more of theplurality of website hosting services to meet a website servicerequirement. Further, the method may include combining the one or moreadapted website hosting services to provide a service package. Themethod may also include serving a plurality of different servicepackages to at least a plurality of unrelated websites.

In an embodiment, a method of website hosting is provided. The methodmay include serving a plurality of website hosting services from aplurality of service pools. A service pool may include a plurality ofservers each configured to serve the same website hosting service. Theplurality of service pools may include a cloud computing based serverarchitecture, a grid computing based server architecture, and the like.The method may include adapting a website hosting service from at leasttwo of the plurality of service pools to meet website servicerequirements of a plurality of unrelated websites. The method mayfurther include combining the adapted website hosting service from theat least two of the plurality of service pools to provide a plurality ofdifferent service packages for the plurality of unrelated websites.

In an embodiment, a method of website hosting is provided. The methodmay include serving a plurality of website hosting services. At leasttwo of the plurality of website hosting services may be served fromdifferent servers. The method may include deploying any of the pluralityof website hosting services to meet website service requirements of aplurality of unrelated websites. Further, the method may includeaccessing, with at least one deployed website hosting service, data froma shared data structure that maintains data for at least a plurality ofthe unrelated websites. The shared data structure may be configured in adistributed database. Further, the shared data structure may include avirtual file system. The shared data structure may maintain data thatmay facilitate configuring any one of the plurality of website hostingservices to be deployed to serve any one of the plurality of unrelatedwebsites. In the embodiment, the shared data structure may be accessibleto a plurality of servers configured into service pools for at least oneof configuring and deploying any one or more of the plurality of websitehosting services. The shared data structure may include data securityfeatures to ensure secure separation of data for at least a plurality ofthe unrelated websites. Further, a web hosting architecture for servingthe plurality of website hosting services may include a cloud computingbased server architecture, a grid computing based server architecture,and the like. In an embodiment, a method of website hosting is provided.The method may include serving a plurality of website hosting servicesfrom a plurality of service pools. A service pool may include aplurality of servers each configured to serve the same website hostingservice. The plurality of service pools may include a cloud computingbased server architecture, a grid computing based server architecture, avirtual server based architecture, and the like. The method may includeadapting a website hosting service from at least two of the plurality ofservice pools to meet website service requirements of a plurality ofunrelated websites. Further, the method may include configuring a serverto serve website hosting services from a plurality of service pools. Theserver may be configured to support a plurality of virtual servers. Eachvirtual server may provide services of one of the plurality of servicepools. At least a portion of the plurality of virtual servers mayprovide services from two or more of the plurality of services pools.The method may further include combining the adapted website hostingservice from the at least two of the plurality of service pools toprovide a plurality of different service packages for the plurality ofunrelated websites.

In an embodiment, a method of website hosting is provided. The methodmay include serving a plurality of website hosting services from aplurality of service pools. Each service pool may serve one websitehosting service. The service pool may include a plurality of serverseach configured to serve the same website hosting service. The methodmay include providing a plurality of servers configurable to serve onewebsite hosting service. The plurality of servers may include a cloudcomputing based server architecture, a grid computing based serverarchitecture, a virtual server based architecture, and the like.Further, the method may include determining a demand for serverresources for at least one of the plurality of service pools. The methodmay also include deploying a server from the plurality of servers toserve the one website hosting service served by the at least one of theplurality of service pools based on the server demand for the at leastone of the plurality of service pools. The server may be configured tosupport a plurality of virtual servers. Each virtual server may provideservices of one of the plurality of service pools. At least a portion ofthe plurality of virtual servers may provide services from two or moreof the plurality of services pools. The method may further includeadapting a website hosting service from at least two of the plurality ofservice pools to meet website service requirements of a plurality ofunrelated websites.

In an embodiment, a method of website hosting is provided. The methodmay include serving a plurality of website hosting services. At leasttwo of the plurality of website hosting services may be served fromdifferent servers. The method may include adapting one or more of theplurality of website hosting services to meet website servicerequirements. Further, the method may include combining the one or moreadapted website hosting services to provide a plurality of servicepackages. The method may also include configuring the plurality ofservice packages into different market-specific offerings. A distinctpackage of services may be described differently in a first marketspecific offering than in a second market specific offering. At least afirst distinct package of services and a second distinct package ofservices may be marketed through a specific market specific offering.The method may include offering the different market-specific offeringsthrough a plurality of websites. In addition, the method may includeserving the plurality of different service packages to at least aplurality of unrelated websites.

In an embodiment, a method of website hosting is provided. The methodmay include serving a plurality of website hosting services. At leasttwo of the plurality of website hosting services may be served fromdifferent servers. The method may include adapting one or more of theplurality of website hosting services to meet a website servicerequirement. Further, the method may include combining the one or moreadapted website hosting services to provide a plurality of differentservice packages to be served to at least a plurality of unrelatedwebsites. The different market specific offerings may include differentbrands, messages, service terms, pricing structures, and the like, forthe offerings. Further, a plurality of different service packages may bemarketed through one of the plurality of marketing websites. The methodmay further include presenting, in an account service user interface ofa website hosting account, visual elements that may be consistent withone of the plurality of market-specific offerings through which thewebsite hosting account was initiated. The visual elements that areconsistent may be provided by one or more servers using a code libraryand in combination with skins that may be associated with the marketspecific offering. In the embodiment, two market specific offerings mayoffer the same distinct service package at two different pricingstructures.

In an embodiment, a method of website hosting is provided. The methodmay include serving a plurality of website hosting services. At leasttwo of the plurality of website hosting services may be served fromdifferent servers. The method may include adapting one or more of theplurality of website hosting services to meet website servicerequirements. Further, the method may include combining the one or moreadapted website hosting services to provide a plurality of servicepackages. The method may include configuring the plurality of servicepackages into different market-specific offerings. In the embodiment,the different market specific offerings may include different brands,different messages, different service terms and conditions, differentpricing structures, and the like, for the offerings. Further, a distinctservice package may be included with a market specific offering. Aplurality of distinct service packages may be marketed through one ofthe plurality of marketing websites. Two market specific offerings mayoffer the same distinct service package at two different pricingstructures. The method may include offering the differentmarket-specific offerings through a plurality of websites. The methodmay also include providing information to service representativessupporting a plurality of different market-specific offerings that mayfacilitate supporting a specific service package based on a specificmarket-specific offering. The information that may facilitate providingthe appropriate service may be sourced from a common data store that maybe accessible to a plurality of service representatives. The servicerepresentatives may be provided with information that may facilitateproviding the appropriate service by an operational support system thatmay facilitate associating a client support request with a marketspecific offering.

In an embodiment, a CRM system is provided. The CRM system may include aplurality of website hosting modules that may be configured as servicepools to provide website hosting services to a plurality of unrelatedwebsites. A portion of the website hosting services may be adapted andcombined into a service package to meet website service requirements.The CRM system may include an operational support system module formaking data for each of the plurality of website hosting modulesaccessible. Further, the CRM system may include a customer relationshipmanagement module for facilitating client and agent interactions byenabling access by the client and agent to the data that may be madeaccessible by the operational support system.

In another embodiment, a CRM system is provided. The CRM system mayinclude a plurality of website hosting modules that may be connected toprovide website hosting services to a plurality of unrelated websites. Aportion of the website hosting services may be deployed to meet websiteservice requirements. At least one of the deployed website hostingservices may be configured to access data from a shared data structuremodule of the plurality of website hosting modules that may maintaindata for at least a plurality of unrelated websites. Further, the CRMsystem may include an operational support system module for making datafor each of the plurality of website hosting modules accessible. Theoperational support system may facilitate access to data associated withany of: business operations, a service pool platform, a load balancer,third party services, a common data store, skins and code library,clients, a CRM workflow, an analytics facility, and the like. Inaddition, the CRM system may include a customer relationship managementmodule for facilitating client and agent interactions by enabling accessby the client and agent to the data that may be made accessible by theoperational support system.

In an embodiment, a CRM system is provided. The CRM system may include aplurality of website hosting modules that may be configured as servicepools to provide website hosting services to a plurality of unrelatedwebsites. A portion of the website hosting services may be adapted andcombined into a service package to meet website service requirements.The method may include an operational support system module for makingdata for each of the plurality of website hosting modules accessible.Further, the CRM system may include a customer relationship managementmodule for facilitating client and agent interactions by enabling accessby the client and agent to the data that may be made accessible by theoperational support system. The client and agent interactions may beorganized into a workflow for handling a client problem.

In another embodiment, a CRM system is provided. The CRM system mayinclude a plurality of website hosting modules that may be connected toprovide website hosting services to a plurality of unrelated websites. Aportion of the website hosting services may be deployed to meet websiteservice requirements. At least one of the deployed website hostingservices may be configured to access data from a shared data structuremodule of the plurality of website hosting modules that may maintaindata for at least a plurality of unrelated websites. Further, the CRMsystem may include an operational support system module for making datafor each of the plurality of website hosting modules accessible. Theoperational support system may facilitate access to data associated withany of: business operations, a service pool platform, a load balancer,third party services, a common data store, skins and code library,clients, a CRM workflow, an analytics facility, and the like. Inaddition, the CRM system may include a customer relationship managementmodule for facilitating client and agent interactions by enabling accessby the client and agent to the data that may be made accessible by theoperational support system. The client and agent interactions may beorganized into a workflow for handling a client problem.

In an embodiment, a CRM system is provided. The CRM system may include aplurality of website hosting modules that may be configured as servicepools to provide website hosting services to a plurality of unrelatedwebsites. A portion of the website hosting services may be adapted andcombined into a service package to meet website service requirements.The CRM system may include an operational support system module formaking data for each of the plurality of website hosting modulesaccessible. Further, the CRM system may include a customer relationshipmanagement module for facilitating client and agent interactions byenabling access by the client and agent to the data that may be madeaccessible by the operational support system. The CRM system may includea module for reporting data relevant to a business function.

In another embodiment, a CRM system is provided. The CRM system mayinclude a plurality of website hosting modules that may be connected toprovide website hosting services to a plurality of unrelated websites. Aportion of the website hosting services may be deployed to meet websiteservice requirements. At least one of the deployed website hostingservices may be configured to access data from a shared data structuremodule of the plurality of website hosting modules that may maintaindata for at least a plurality of unrelated websites. Further, the CRMsystem may include an operational support system module for making datafor each of the plurality of website hosting modules accessible. Theoperational support system may facilitate access to data associated withany of: business operations, a service pool platform, a load balancer,third party services, a common data store, skins and code library,clients, a CRM workflow, an analytics facility, and the like. Inaddition, the CRM system may include a customer relationship managementmodule for facilitating client and agent interactions by enabling accessby the client and agent to the data that may be made accessible by theoperational support system. The CRM system may include a module forreporting data relevant to a business function.

In an embodiment, a method of website hosting is provided. The methodmay include serving a plurality of website hosting services. At leasttwo of the plurality of website hosting services may be served fromdifferent servers. The method may further include adapting one or moreof the plurality of website hosting services to meet a website servicerequirement. In addition, the method may include combining the one ormore adapted website hosting services to provide a service package. Atleast one of the plurality of website hosting services serving a thirdparty interface may allow access to a third party service in the servicepackage. In the embodiment, the third party service may be accessible inthe distinct service package consistent with a market-specific serviceoffering. Further, the third party service may be offered as a componentof the service package. The third party service may be accessiblethrough a software API, a software plug-in, a link to a third-partyservice, and the like. The link may be a URL to a third-party website, acustomized link that may activate a third-party service, customized withmarket-specific service offering information, and the like. Also, thethird party interface may include one of an API, a plug-in, a webservice, a URL redirector, and the like. The third party service may bepresented to a first website hosting client with a look and feel thatmay be distinct from a look and feel of the third party servicepresented to a second website hosting client. Further, the method mayinclude serving a plurality of different service packages to at least aplurality of unrelated websites.

In an embodiment, a method of automatic website hosting servicemigration is provided. The method may include determining a plurality ofwebsite-specific hosting services provided by a first website hostingarchitecture that may serve the plurality of website-specific hostingservices to a specific website. Serving the corresponding common websitehosting service may include adapting the common website hosting serviceto meet website hosting requirements for a plurality of unrelatedwebsites. The method may further include analyzing the plurality ofwebsite-specific hosting services to identify at least one of theplurality of website-specific hosting services that may correspond to acommon website hosting service of a second website hosting architecture.Further, the first website hosting architecture may include data storagededicated to each website. The second website hosting architecture mayinclude shared data storage that may maintain data for at least aplurality of the unrelated websites. The second website hostingarchitecture may serve the plurality of common website hosting servicesfrom a plurality service pools. Each service pool of the plurality ofservice pools may provide a single website hosting service of theplurality of common website hosting services. The second website hostingarchitecture may serve a plurality of common website hosting services toa plurality of unrelated websites. Further, each of a plurality of thesingle website hosting services may be adapted and provided to a websitein a service package that may be representative of the plurality ofwebsite-specific hosting services that may be provided to the website bythe first website hosting architecture. In addition, the method mayinclude serving the corresponding common website hosting service fromthe second website hosting architecture, in response to a request forthe at least one of the plurality of website-specific hosting services.In an embodiment serving the corresponding common website hostingservice includes determining a migration status for the at least one ofthe plurality of website-specific hosting services and serving one ofthe at least one of the plurality of website-specific hosting servicesfrom the first website hosting architecture and the corresponding commonwebsite hosting service from the second website hosting architecturebased on the determination. Alternatively an embodiment, the firstwebsite hosting architecture comprises one or more of a grid computingenvironment, a cloud computing environment, and a virtual computingenvironment.

In another embodiment, a method of automatic website hosting servicemigration is provided. The method may include determining a plurality ofwebsite hosting services that may be provided to a website from a firstwebsite hosting architecture that may serve a plurality of commonwebsite hosting services to a plurality of unrelated websites. The firstwebsite hosting architecture may serve the plurality of common websitehosting services from a plurality service pools. Each service pool ofthe plurality of service pools may provide a single website hostingservice of the plurality of common website hosting services. The methodmay further include establishing a website-specific hosting service foreach of the plurality of determined website hosting services to beserved from a second website hosting architecture that may servewebsite-specific hosting services to a specific website. The secondwebsite hosting architecture may include data storage dedicated to eachwebsite. The first website hosting architecture may include shared datastorage that may maintain data for at least a plurality of the unrelatedwebsites. In addition, the method may include serving the correspondingwebsite-specific hosting service from the second website hostingarchitecture, in response to a request for at least one of the pluralityof website hosting services that may be provided to the website from thefirst website hosting architecture. The second website hostingarchitecture may comprise one of a grid and a cloud computingenvironment and optionally, the first website hosting architecturecomprises one of a grid and a cloud computing environment.Alternatively, the first website hosting architecture comprises one of agrid and a cloud computing environment and the second website hostingarchitecture comprises a virtual computing environment.

In an embodiment, a method of automatic website hosting servicemigration is provided. The method may include determining a plurality ofwebsite-specific hosting services provided by a first website hostingarchitecture that may serve the plurality of website-specific hostingservices to a specific website by a single server. Serving thecorresponding common website hosting service may include adapting thecommon website hosting service to meet website hosting requirements fora plurality of unrelated websites. The method may further includeanalyzing the plurality of website-specific hosting services to identifyat least one of the plurality of website-specific hosting services thatmay correspond to a common website hosting service of a second websitehosting architecture. Further, the first website hosting architecturemay include data storage dedicated to each website. The second websitehosting architecture may include shared data storage that may maintaindata for at least a plurality of the unrelated websites. The secondwebsite hosting architecture may serve the plurality of common websitehosting services from a plurality service pools. Each service pool ofthe plurality of service pools may provide a single website hostingservice of the plurality of common website hosting services. Each of aplurality of the single website hosting services may be adapted andprovided to a website in a service package that may be representative ofthe plurality of website-specific hosting services provided to thewebsite by the first website hosting architecture. In addition, theplurality of website-specific hosting services provided to a specificwebsite by the single server may be provided as a service package ofadapted services by a portion of the plurality of servers. The servicepackage may be derived from the plurality of common website hostingservices of the second website hosting architecture. Also, the methodmay include serving the corresponding common website hosting servicefrom any of a plurality of servers of the second website hostingarchitecture, in response to a request for the at least one of theplurality of website-specific hosting services. The second websitehosting architecture may serve a plurality of common website hostingservices to a plurality of unrelated websites from the plurality ofservers.

In another embodiment, a method of automatic website hosting servicemigration is provided. The method may include determining a plurality ofwebsite hosting services being provided to a website from a firstwebsite hosting architecture that may serve a plurality of commonwebsite hosting services to a plurality of unrelated websites from aplurality of servers. The first website hosting architecture may servethe plurality of common website hosting services from a pluralityservice pools. Each service pool of the plurality of service pools mayprovide a single website hosting service of the plurality of commonwebsite hosting services. The method may further include establishing awebsite-specific hosting service for each of the plurality of determinedwebsite hosting services to be served from a second website hostingarchitecture that may serve a plurality of website-specific hostingservices to a specific website by a single server. Further, the secondwebsite hosting architecture may include data storage dedicated to eachwebsite. The first website hosting architecture may include shared datastorage that may maintain data for at least a plurality of the unrelatedwebsites. In addition, the method may include serving the correspondingwebsite-specific hosting service from the second website hostingarchitecture, in response to a request for at least one of the pluralityof website hosting services that may be provided to the website from thefirst website hosting architecture.

In an embodiment, a method of automatic website hosting servicemigration is provided. The method may include determining a plurality ofwebsite-specific hosting services that may be provided by a firstwebsite hosting architecture that may serve the plurality ofwebsite-specific hosting services to a specific website by awebsite-dedicated server. Serving the corresponding common websitehosting service may include adapting the common website hosting serviceto meet website hosting requirements for a plurality of unrelatedwebsites. The method may further include analyzing the plurality ofwebsite-specific hosting services to identify at least one of theplurality of website-specific hosting services that may correspond to acommon website hosting service of a second website hosting architecture.Further, the first website hosting architecture may include data storagededicated to each website. The second website hosting architecture mayinclude shared data storage that may maintain data for at least aplurality of the unrelated websites. The second website hostingarchitecture may serve the plurality of common website hosting servicesfrom a plurality service pools. Each service pool of the plurality ofservice pools may provide a single website hosting service of theplurality of common website hosting services. Each of a plurality of thesingle website hosting services may be adapted and provided to a websitein a service package that may be representative of the plurality ofwebsite-specific hosting services provided to the website by the firstwebsite hosting architecture. The website-dedicated server of the firstwebsite hosting architecture may have one or more substantiallyduplicate servers for backup purposes. In addition, the method mayinclude serving the corresponding common website hosting service fromany of a plurality of servers of the second website hostingarchitecture, in response to a request for the at least one of theplurality of website-specific hosting services. The second websitehosting architecture may serve a plurality of common website hostingservices to a plurality of unrelated websites from the plurality ofservers using a cloud computing architecture.

In an embodiment, a method of automatic website hosting servicemigration is provided. The method may include determining a plurality ofwebsite hosting services that may be provided to a website from a firstwebsite hosting architecture that may serve a plurality of commonwebsite hosting services to a plurality of unrelated websites from aplurality of servers using a cloud computing architecture. Further, thefirst website hosting architecture may serve the plurality of commonwebsite hosting services from a plurality service pools. Each servicepool of the plurality of service pools may provide a single websitehosting service of the plurality of common website hosting services. Themethod may further include establishing a website-specific hostingservice for each of the plurality of determined website hosting servicesthat may be served from a second website hosting architecture that mayserve a plurality of website-specific hosting services to a specificwebsite by a website-dedicated server. The second website hostingarchitecture may include data storage dedicated to each website. Thefirst website hosting architecture may include shared data storage thatmay maintain data for at least a plurality of the unrelated websites. Inaddition, the method may include serving the correspondingwebsite-specific hosting service from the second website hostingarchitecture, in response to a request for at least one of the pluralityof website hosting services that may be provided to the website from thefirst website hosting architecture.

In an embodiment, a method of automatic website hosting servicemigration is provided. The method may include determining a plurality ofwebsite-specific hosting services that may be provided by a firstwebsite hosting architecture that may serve the plurality ofwebsite-specific hosting services to a specific website by awebsite-dedicated server. Further, serving the corresponding commonwebsite hosting service may include adapting the common website hostingservice to meet website hosting requirements for a plurality ofunrelated websites. The method may also include analyzing the pluralityof website-specific hosting services to identify at least one of theplurality of website-specific hosting services that may correspond to acommon website hosting service of a second website hosting architecture.The first website hosting architecture may include data storagededicated to each website. The second website hosting architecture mayinclude shared data storage that may maintain data for at least aplurality of the unrelated websites. Furthermore, the second websitehosting architecture may serve the plurality of common website hostingservices from a plurality service pools. Each service pool of theplurality of service pools may provide a single website hosting serviceof the plurality of common website hosting services. In addition, eachof a plurality of the single website hosting services may be adapted andprovided to a website in a service package that may be representative ofthe plurality of website-specific hosting services that may be providedto the website by the first website hosting architecture. Also, thewebsite-dedicated server of the first website hosting architecture mayhave one or more substantially duplicate servers for backup purposes.The method may further include serving the corresponding common websitehosting service from any of a plurality of servers of the second websitehosting architecture, in response to a request for the at least one ofthe plurality of website-specific hosting services. The second websitehosting architecture may serve a plurality of common website hostingservices to a plurality of unrelated websites from the plurality ofservers using a grid computing architecture. In an embodiment servingthe corresponding common website hosting service includes determining amigration status for the at least one of the plurality ofwebsite-specific hosting services and serving one of the at least one ofthe plurality of website-specific hosting services from the firstwebsite hosting architecture and the corresponding common websitehosting service from the second website hosting architecture based onthe determination. Alternatively an embodiment, the first websitehosting architecture comprises one or more of a grid computingenvironment, a cloud computing environment, and a virtual computingenvironment.

In another embodiment, a method of automatic website hosting servicemigration is provided. The method may include determining a plurality ofwebsite hosting services that may be provided to a website from a firstwebsite hosting architecture that may serve a plurality of commonwebsite hosting services to a plurality of unrelated websites from theplurality of servers using a grid computing architecture. The firstwebsite hosting architecture may serve the plurality of common websitehosting services from a plurality service pools. Each service pool ofthe plurality of service pools may provide a single website hostingservice of the plurality of common website hosting services. Inaddition, the method may include establishing a website-specific hostingservice for each of the plurality of determined website hosting servicesto be served from a second website hosting architecture that may serve aplurality of website-specific hosting services to a specific website bya website-dedicated server. The second website hosting architecture mayinclude data storage that may be dedicated to each website. Further, thefirst website hosting architecture may include shared data storage thatmay maintain data for at least a plurality of the unrelated websites.The method may also include serving the corresponding website-specifichosting service from the second website hosting architecture, inresponse to a request for at least one of the plurality of websitehosting services being provided to the website from the first websitehosting architecture. The second website hosting architecture maycomprise one of a grid and a cloud computing environment and optionally,the first website hosting architecture comprises one of a grid and acloud computing environment. Alternatively, the first website hostingarchitecture comprises one of a grid and a cloud computing environmentand the second website hosting architecture comprises a virtualcomputing environment.

In an embodiment, a method of automatic website hosting servicemigration is provided. The method may include determining a plurality ofwebsite-specific hosting services that may be provided by a firstwebsite hosting architecture that may serve the plurality ofwebsite-specific hosting services to a specific website by awebsite-dedicated server. Further, serving the corresponding commonwebsite hosting service may include adapting the common website hostingservice to meet website hosting requirements for a plurality ofunrelated websites. The first website hosting architecture may includedata storage dedicated to each website. The second website hostingarchitecture may include shared data storage that may maintain data forat least a plurality of the unrelated websites. The second websitehosting architecture may serve the plurality of common website hostingservices from a plurality service pools. Each service pool of theplurality of service pools may provide a single website hosting serviceof the plurality of common website hosting services. Further, each of aplurality of the single website hosting services may be adapted andprovided to a website in a service package that may be representative ofthe plurality of website-specific hosting services that may be providedto the website by the first website hosting architecture. Thewebsite-dedicated server of the first website hosting architecture mayhave one or more substantially duplicate servers for backup purposes.The method may also include analyzing the plurality of website-specifichosting services to identify at least one of the plurality ofwebsite-specific hosting services that may correspond to a commonwebsite hosting service of a second website hosting architecture. Themethod may include serving the corresponding common website hostingservice from any of a plurality of servers of the second website hostingarchitecture, in response to a request for the at least one of theplurality of website-specific hosting services. The second websitehosting architecture may serve a plurality of common website hostingservices to a plurality of unrelated websites from the plurality ofservers using at least one of a cloud and a grid computing architecture.In an embodiment serving the corresponding common website hostingservice includes determining a migration status for the at least one ofthe plurality of website-specific hosting services and serving one ofthe at least one of the plurality of website-specific hosting servicesfrom the first website hosting architecture and the corresponding commonwebsite hosting service from the second website hosting architecturebased on the determination. Alternatively an embodiment, the firstwebsite hosting architecture comprises one or more of a grid computingenvironment, a cloud computing environment, and a virtual computingenvironment.

In another embodiment, a method of automatic website hosting servicemigration is provided. The method may include determining a plurality ofwebsite hosting services that may be provided to a website from a firstwebsite hosting architecture that may serve a plurality of commonwebsite hosting services to a plurality of unrelated websites from theplurality of servers using at least one of a cloud and a grid computingarchitecture. The second website hosting architecture may include datastorage dedicated to each website, and wherein the first website hostingarchitecture comprises shared data storage that maintains data for atleast a plurality of the unrelated websites. Further, the first websitehosting architecture may serve the plurality of common website hostingservices from a plurality service pools. Each service pool of theplurality of service pools may provide a single website hosting serviceof the plurality of common website hosting services. The method mayfurther include establishing a website-specific hosting service for eachof the plurality of determined website hosting services to be servedfrom a second website hosting architecture that may serve a plurality ofwebsite-specific hosting services to a specific website by awebsite-dedicated server. In addition, the method may include servingthe corresponding website-specific hosting service from the secondwebsite hosting architecture, in response to a request for at least oneof the plurality of website hosting services that may be provided to thewebsite from the first website hosting architecture. The second websitehosting architecture may comprise one of a grid and a cloud computingenvironment and optionally, the first website hosting architecturecomprises one of a grid and a cloud computing environment.Alternatively, the first website hosting architecture comprises one of agrid and a cloud computing environment and the second website hostingarchitecture comprises a virtual computing environment.

In an embodiment, a method of automatic website hosting servicemigration may include determining a plurality of website-specifichosting services that may be provided by a first website hostingarchitecture that may serve the plurality of website-specific hostingservices to at least one of a client's websites by a server that may bededicated to serving the services necessary for the client's websites.Further, serving the corresponding common website hosting service mayinclude adapting the common website hosting service to meet websitehosting requirements for a plurality of unrelated websites. The methodmay include analyzing the plurality of website-specific hosting servicesto identify at least one of the plurality of website-specific hostingservices that may correspond to a common website hosting service of asecond website hosting architecture. The first website hostingarchitecture may include data storage dedicated to each client. Thesecond website hosting architecture may include shared data storage thatmay maintain data for at least a plurality of the unrelated clients.Further, the second website hosting architecture may serve the pluralityof common website hosting services from a plurality service pools. Eachservice pool of the plurality of service pools may provide a singlewebsite hosting service of the plurality of common website hostingservices. Each of a plurality of the single website hosting services maybe adapted and provided to a website in a service package that may berepresentative of the plurality of website-specific hosting servicesprovided to the website by the first website hosting architecture. Inaddition, the website-dedicated server of the first website hostingarchitecture may have one or more substantially duplicate servers forbackup purposes. The method may also include serving the correspondingcommon website hosting service from any of a plurality of shared serversof the second website hosting architecture, in response to a request forthe at least one of the plurality of website-specific hosting services.The second website hosting architecture may serve a plurality ofunrelated clients from a plurality of shared servers. The plurality ofshared servers of the second website hosting architecture may operate ina cloud computing environment, a grid computing environment, and thelike. In an embodiment serving the corresponding common website hostingservice includes determining a migration status for the at least one ofthe plurality of website-specific hosting services and serving one ofthe at least one of the plurality of website-specific hosting servicesfrom the first website hosting architecture and the corresponding commonwebsite hosting service from the second website hosting architecturebased on the determination. Alternatively an embodiment, the firstwebsite hosting architecture comprises one or more of a grid computingenvironment, a cloud computing environment, and a virtual computingenvironment.

In another embodiment, a method of automatic website hosting servicemigration may include determining a plurality of website hostingservices that may be provided to a website from a first website hostingarchitecture that may serve a plurality of unrelated clients from aplurality of shared servers. The first website hosting architecture mayserve the plurality of common website hosting services from a pluralityservice pools. Each service pool of the plurality of service pools mayprovide a single website hosting service of the plurality of commonwebsite hosting services. Further, the method may include establishing awebsite-specific hosting service for each of the plurality of determinedwebsite hosting services to be served from a second website hostingarchitecture that may serve the plurality of website-specific hostingservices to at least one of a client's websites by a server that may bededicated to serving the services necessary for the client's websites.The second website hosting architecture may include data storagededicated to each website. The first website hosting architecture mayinclude shared data storage that may maintain data for at least aplurality of the unrelated websites. In addition, the method may includeserving the corresponding website-specific hosting service from thesecond website hosting architecture, in response to a request for atleast one of the plurality of website hosting services that may beprovided to the website from the first website hosting architecture. Thesecond website hosting architecture may comprise one of a grid and acloud computing environment and optionally, the first website hostingarchitecture comprises one of a grid and a cloud computing environment.Alternatively, the first website hosting architecture comprises one of agrid and a cloud computing environment and the second website hostingarchitecture comprises a virtual computing environment.

In an embodiment, a method of automatic website hosting servicemigration is provided. The method may include determining a plurality offirst common website hosting services that may be provided by a firstwebsite hosting architecture that may serve a plurality of commonservices from a plurality of machines to a plurality of unrelatedwebsites. The first website hosting architecture may be a cloudcomputing environment, a grid computing environment, and the like.Further, the plurality of machines of the first website hostingarchitecture may be configured into a plurality of common service pools.The method may further include analyzing the plurality of first commonwebsite hosting services to identify at least one of the plurality offirst common website hosting services that may correspond to a commonwebsite hosting service of a second website hosting architecture. In theembodiment, the second website hosting architecture may be a cloudcomputing environment, a grid computing environment, and the like. Inaddition, the plurality of machines of the second website hostingarchitecture may be configured into a plurality of common service pools.The method may also include serving the corresponding common websitehosting service from the second website hosting architecture, inresponse to a request for the at least one of the plurality of firstcommon website hosting services. The second website hosting architecturemay serve a plurality of common website hosting services from aplurality of machines to a plurality of unrelated websites. In anembodiment serving the corresponding common website hosting serviceincludes determining a migration status for the at least one of theplurality of website-specific hosting services and serving one of the atleast one of the plurality of website-specific hosting services from thefirst website hosting architecture and the corresponding common websitehosting service from the second website hosting architecture based onthe determination. Alternatively an embodiment, the first websitehosting architecture comprises one or more of a grid computingenvironment, a cloud computing environment, and a virtual computingenvironment.

In an embodiment, a method of automatic website hosting servicemigration is provided. The method may include determining a plurality ofwebsite-specific hosting services that may be provided by a firstwebsite hosting architecture that may serve the plurality ofwebsite-specific hosting services to at least one of a client's websitesby a virtual server that may be dedicated to serving the servicesnecessary for the client's websites. Further, serving the correspondingcommon website hosting service may include adapting the common websitehosting service to meet website hosting requirements for a plurality ofunrelated websites. The first website hosting architecture may includedata storage dedicated to each client. The second website hostingarchitecture may include shared data storage that may maintain data forat least a plurality of the unrelated clients. In addition, thewebsite-dedicated virtual server of the first website hostingarchitecture may have one or more substantially duplicate virtualservers for backup purposes. The plurality of shared servers of thesecond website hosting architecture may operate in a cloud computingenvironment, a grid computing environment, and the like. The method mayalso include analyzing the plurality of website-specific hostingservices to identify at least one of the plurality of website-specifichosting services that may correspond to a common website hosting serviceof a second website hosting architecture. The second website hostingarchitecture may serve the plurality of common website hosting servicesfrom a plurality service pools. Each service pool of the plurality ofservice pools may provide a single website hosting service of theplurality of common website hosting services. Further, each of aplurality of the single website hosting services may be adapted andprovided to a website in a service package that may be representative ofthe plurality of website-specific hosting services provided to thewebsite by the first website hosting architecture. The method mayinclude serving the corresponding common website hosting service fromany of a plurality of shared servers of the second website hostingarchitecture, in response to a request for the at least one of theplurality of website-specific hosting services. The second websitehosting architecture may serve a plurality of unrelated clients from aplurality of shared servers. The second website hosting architecture maycomprise one of a grid and a cloud computing environment and optionally,the first website hosting architecture comprises one of a grid and acloud computing environment. Alternatively, the first website hostingarchitecture comprises one of a grid and a cloud computing environmentand the second website hosting architecture comprises a virtualcomputing environment.

In another embodiment, a method of automatic website hosting servicemigration is provided. The method may include determining a plurality ofwebsite hosting services that may be provided to a website from a firstwebsite hosting architecture that may serve a plurality of unrelatedclients from a plurality of shared servers. The first website hostingarchitecture may serve the plurality of common website hosting servicesfrom a plurality service pools. Each service pool of the plurality ofservice pools may provide a single website hosting service of theplurality of common website hosting services. Further, the method mayinclude establishing a website-specific hosting service for each of theplurality of determined website hosting services to be served from asecond website hosting architecture that may serve the plurality ofwebsite-specific hosting services to at least one of a client's websitesby a virtual server that may be dedicated to serving the servicesnecessary for the client's websites. The second website hostingarchitecture may include data storage dedicated to each website. Thefirst website hosting architecture may include shared data storage thatmay maintain data for at least a plurality of the unrelated websites. Inaddition, the method may include serving the correspondingwebsite-specific hosting service from the second website hostingarchitecture, in response to a request for at least one of the pluralityof website hosting services that may be provided to the website from thefirst website hosting architecture. In an embodiment serving thecorresponding common website hosting service includes determining amigration status for the at least one of the plurality ofwebsite-specific hosting services and serving one of the at least one ofthe plurality of website-specific hosting services from the firstwebsite hosting architecture and the corresponding common websitehosting service from the second website hosting architecture based onthe determination. Alternatively an embodiment, the first websitehosting architecture comprises one or more of a grid computingenvironment, a cloud computing environment, and a virtual computingenvironment.

In an embodiment, a method of automatic website hosting servicemigration is provided. The method may include determining a plurality ofIP addresses served by a first website hosting architecture to bemigrated to a second website hosting architecture. The second websitehosting architecture may be a cloud computing architecture, a gridcomputing architecture, and the like. The method may further includeconfiguring a virtual network that may connect the first website hostingarchitecture with the second website hosting architecture to facilitateresponding to requests to access the plurality of IP addresses duringmigration. In addition, the method may include serving data via thevirtual network that may be suitable for a response to a request toaccess resources accessible through one of the plurality of IP addressesfrom one of the first website hosting architecture and the secondwebsite hosting architecture based on a status of migration of theresources. Further, the data may be sourced from the second websitehosting architecture when the status of migration may indicate the datathat may be suitable for a response has been migrated. The data may alsobe sourced from the first website hosting architecture when the statusof migration may indicate that the data that may be suitable for aresponse has not been migrated.

In another embodiment, a method of automatic website hosting servicemigration is provided. The method may include determining a plurality ofwebsite hosting services that may be provided by a first website hostingarchitecture to at least one website. The first website hostingarchitecture may serve the plurality of website hosting services to aspecific website. The method may further include analyzing the pluralityof website hosting services to identify at least one of the plurality ofwebsite hosting services that may correspond to a common website hostingservice of a second website hosting architecture. The second websitehosting architecture may serve a plurality of common website hostingservices to a plurality of unrelated websites. In addition, the methodmay include configuring a virtual network that may connect the firstwebsite hosting architecture with the second website hostingarchitecture to facilitate responding to a network request to accessservices that may be provided to the at least one website duringmigration. The method may also include serving one of the at least oneof the plurality of website hosting services from the first websitehosting architecture and the corresponding common website hostingservice from the second website hosting architecture via the virtualnetwork based on a migration status of the at least one website, inresponse to the network request. In an embodiment serving thecorresponding common website hosting service includes determining amigration status for the at least one of the plurality ofwebsite-specific hosting services and serving one of the at least one ofthe plurality of website-specific hosting services from the firstwebsite hosting architecture and the corresponding common websitehosting service from the second website hosting architecture based onthe determination. Alternatively an embodiment, the first websitehosting architecture comprises one or more of a grid computingenvironment, a cloud computing environment, and a virtual computingenvironment.

In an embodiment, a method of survival analysis is provided. The methodmay include receiving website hosting client data for a plurality ofclients. The website hosting client attribute data may include clientin-service data. Further, the client attribute data may include newclient origination rate data. The website hosting client data may bereceived from a module of a common service website hosting platform.Further, the module may be an operational support system module. Themethod may further include calculating, with a server, a model ofwebsite hosting client survival by applying a population survivalanalysis algorithm to the website hosting client data. Further,calculating a model of website hosting client survival may includeincorporating third-party data in the model. The third-party data mayinclude at least one of unemployment data, interest rate data,macroeconomic data, and the like.

In another embodiment, a method of survival analysis is provided. Themethod may include receiving website hosting client attribute data for aplurality of clients. The website hosting client attribute data mayinclude client in-service data. Further, the client attribute data mayinclude new client origination rate data. The website hosting clientdata may be received from a module of a common service website hostingplatform. The module may be an operational support system module. Themethod may further include applying a survival analysis algorithm to thedata. In addition, the method may include determining a survival ratefor a second plurality of clients based on a survival rate of a firstplurality of clients. The first and second pluralities of clients haveat least two common website hosting client attributes. Further,determining a survival rate may include incorporating third-party datato determine the survival rate. The third-party data may include atleast one of unemployment data, interest rate data, macroeconomic data,and the like.

In yet another embodiment, a method of survival analysis of websitehosting clients is provided. The method may include extracting websitehosting related data for a plurality of clients from a plurality of datasources accessible to a plurality of servers in a website hostingsystem. The plurality of clients may be at least one of unrelated andunaffiliated. Further, extracting website hosting related data may beexecuted by an operational support system module of the website hostingsystem. The method may include selecting a survival analysis algorithm.The method may further include applying the selected survival analysisalgorithm to the extracted website hosting related data to generatesurvival analysis data for a first portion of the plurality of clients.In addition, the method may include determining a second portion of theplurality of clients based on similarities to the first portion of theplurality of clients. Further, the method may include predictingsurvival for the second portion of the plurality of clients based on thesurvival analysis data and a measure of a degree of similarity to thefirst portion of the plurality of clients. Also, the predicting survivalmay include incorporating third-party data into the prediction. Thethird-party data may include at least one of unemployment data, interestrate data, macroeconomic data, and the like. Further, the websitehosting related data for a plurality of clients may include new clientorigination rate data.

In an embodiment, a method of mapping website hosting product offeringsis provided. The method may include receiving data representing aplurality of web domain offerings that may be available to a pluralityof website hosting clients. The method may include receiving websitehosting client usage data for a portion of the plurality of web domainofferings. Further, the method may include determining similarity amongthe plurality of web domain offerings for a plurality of dimensions ofsimilarity based on analysis of the client usage data with a server. Inaddition, the method may include presenting on an electronic display aportion of the plurality of web domain offerings in a three-dimensionalvisual representation that may use a visual element to represent adegree of similarity among the portion of the plurality of web domainofferings. The visual element may reflect at least one dimension of theplurality of dimensions of similarity. The three dimensional visualrepresentation may be a three dimensional map. Further, the degree ofsimilarity may be determined by correlating client profiles among pairsof offerings. In the embodiment, the visual element may be distance,object size, text size, size of an element connecting one offering toanother and the like. Further, the element connecting one offering toanother may be a directional arrow that may be indicative of the degreeof similarity. The three dimensional visual representation may beadapted based on a dimension of similarity. The dimension of similaritymay be related to one of a product, a service, an offering of a commonservice architecture website hosting service, and the like. Also, themethod may include presenting a user selector for a dimension ofsimilarity that may cause the three-dimensional visual representation toadapt to reflect a dimension of similarity indicated by the userselector.

In another embodiment, a method of charting website hosting productofferings is provided. The method may include receiving data that mayrepresent a plurality of web domain offerings that may be available to aplurality of website hosting clients. The method may also includereceiving website hosting client usage data for a portion of theplurality of web domain offerings. Further, the method may includedetermining similarity among the plurality of web domain offerings for aplurality of dimensions of similarity based on analysis of the clientusage data with a server. In addition, the method may include presentingon an electronic display a portion of the plurality of web domainofferings in a two-dimensional table that may display a degree ofsimilarity for each pair of domain offerings in the portion of theplurality of web domain offerings for at least one dimension of theplurality of dimensions of similarity. The displayed degree ofsimilarity may be determined by correlating client profiles among pairsof offerings. Further, the dimension of similarity may be related to oneof a product, a service, and an offering of a common servicearchitecture website hosting service. In the embodiment, determiningsimilarity may include incorporating third-party data. The third-partydata may include at least one of unemployment data, interest rate data,macroeconomic data, and the like.

In an embodiment, a method of client retention assessment is provided.The method may include receiving website hosting client usage data for aplurality of website hosting services. The method may include analyzingwith a server the website hosting client usage data to determinepatterns of hosting service usage. Further, the method may includeassociating the patterns of hosting service usage with client retentioninformation. The client retention information may include websitehosting client survival analysis results. In addition, the method mayinclude using a server to statistically analyze the associated patternsand client retention information to determine factors that predictwebsite hosting clients not to be retained. In the embodiment, thestatistical analysis may be a covariance analysis. The method mayfurther include identifying at least one website hosting client based onthe determined factors to facilitate website hosting client retention.Identifying at least one website hosting client based on the determinedfactors may include comparing the determined factors to website hostingclient usage data for the plurality of website hosting services.Further, the determined factors that may predict website hosting clientsnot to be retained may be based on website hosting client survivalanalysis results. The determining factors that may predict websitehosting clients not to be retained may include user interaction patternsof prospective clients who may have viewed web domain offerings but maynot have purchased the web domain offerings. The determining factorsthat may predict website hosting clients not to be retained may includeincorporating third-party data therein. The third-party data may includeat least one of unemployment data, interest rate data, macroeconomicdata, and the like.

In an embodiment, a method of client financial results assessment isprovided. The method may include receiving website hosting client usagedata for a plurality of website hosting services. The method may includeanalyzing with a server the website hosting client usage data todetermine patterns of hosting service usage. The website hosting clientusage data may include website hosting client survival analysis results.Further, the method may include associating the patterns of hostingservice usage with client financial results information. In addition,the method may include using a server to statistically analyze theassociated patterns and client financial results information todetermine factors that may predict website hosting clients not toproduce favorable financial results. In the embodiment, the statisticalanalysis may be covariance analysis. The method may further includeidentifying at least one website hosting client based on the determinedfactors to facilitate improving website hosting client financialresults. Further, identifying at least one website hosting client basedon the determined factors may include comparing the determined factorsto website hosting client usage data for the plurality of websitehosting services. The determined factors that may predict websitehosting clients not to produce favorable financial results may be basedon website hosting client survival analysis results. The determiningfactors that may predict website hosting clients not to producefavorable financial results may include user interaction patterns ofprospective clients who may have viewed web domain offerings but may nothave purchased the web domain offerings. Also, the method may includeusing the determined factors to predict the financial impact ofacquisition of a plurality of clients. Further, determining factors thatpredict website hosting clients not to produce favorable financialresults may include incorporating third-party data therein. Thethird-party data may include at least one of unemployment data, interestrate data, macroeconomic data, and the like.

In an embodiment, a method of web domain offerings selection isprovided. The method may include configuring a matrix of web domainofferings and clients who may have purchased at least one of the webdomain offerings. The web domain offerings may represent website hostingservices, packages of website hosting services, and the like. The methodmay include populating the matrix with web domain offering-purchaseinformation for the clients. Further, the method may include processingthe matrix with a random forest algorithm to produce a probability ofpurchase for each entry in the matrix. In addition, the method mayinclude identifying entries in the matrix that may represent favorableprobabilities of a client purchasing a web domain offering.

In another embodiment, a method of targeting offers to clients isprovided. The method may include taking web domain offering purchaseinformation for a plurality of clients. The method may include takingweb domain offering information for a plurality of web domain offerings.Further, the method may include determining with a server a probabilitythat at least a subset of the plurality of clients may purchase at leasta subset of the plurality of web domain offerings. Determining aprobability may include applying a random forest algorithm to the webdomain offering purchase information and the web domain offeringinformation. The method may further include identifying with a server asubset of the plurality of web domain offerings that may representfavorable probabilities of web domain offering purchase for a client. Inaddition, the method may include determining information for web domainofferings not purchased by the plurality of clients. The plurality ofweb domain offerings may include website hosting services. Also, themethod may include determining which of the plurality of web domainofferings may not have been purchased by each of the plurality ofclients.

These and other systems, methods, objects, features, and advantages ofthe present invention will be apparent to those skilled in the art fromthe following detailed description of the preferred embodiment and thedrawings. All documents mentioned herein are hereby incorporated intheir entirety by reference.

BRIEF DESCRIPTION OF THE FIGURES

The invention and the following detailed description of certainembodiments thereof may be understood by reference to the followingfigures:

FIG. 1 depicts a block diagram of the new web hosting architecture;

FIG. 2 depicts an overview of the architecture of an operational supportservice (OSS);

FIG. 3 depicts a schematic block diagram of a common servicearchitecture that supports a website hosting service for providing aplurality of services from the common service architecture;

FIG. 4 depicts a schematic block diagram of a common servicearchitecture that supports a website hosting service for providing aplurality of services from a plurality of service pools;

FIG. 5 depicts a schematic block diagram of a common servicearchitecture, for providing a plurality of services to each of aplurality of [unrelated/unaffiliated] websites;

FIG. 6 depicts a schematic block diagram of a common servicearchitecture that supports a website service for providing a pluralityof services from a plurality of service pools;

FIG. 7 depicts a flowchart that illustrates a method of website hosting;

FIG. 8 depicts a schematic block diagram of a new website hostingplatform that is associated with common service architecture thatsupports multiple branding;

FIG. 9 depicts a schematic block diagram of common service architecturethat supports a website hosting service which provides a plurality ofservices to each of a plurality of unrelated websites;

FIG. 10 depicts a schematic block diagram of common service architecturewith a service representative plug-in;

FIG. 11 depicts a schematic block diagram of a customer relationshipmanagement (CRM) system for accessing data for client and agentinteractions;

FIG. 12 depicts a schematic block diagram of the CRM system of FIG. 11that is configured to facilitate handling a client problem;

FIG. 13 depicts a schematic block diagram of the CRM system of FIG. 11that includes a reporting facility;

FIG. 14 depicts a schematic block diagram of a common servicearchitecture for offering a third party service to a plurality ofwebsites;

FIG. 15 depicts a schematic block diagram of a process for migrating awebsite hosting service from a first website hosting architecture to asecond website hosting architecture;

FIG. 16 depicts a schematic block diagram of a migration process formigration of a web hosting service from server architecture to commonservice architecture;

FIG. 17 depicts a schematic block diagram of a migration process andfacility for migration of a website hosting service from serverarchitecture to common server architecture that is based in a servercloud arrangement;

FIG. 18 depicts a schematic block diagram of an alternate embodiment ofthe migration process of FIG. 17, where the servers of the commonservice architecture that is based in a server grid;

FIG. 19 depicts a schematic block diagram of a migration process formigration of a website hosting service from a one box per multipleclient architecture to a many boxes for many clients architecture;

FIG. 20 depicts a schematic block diagram of a migration process forenabling migration of a web hosting service from a dedicated environmentfor each client to a shared environment for multiple clients;

FIG. 21 depicts a schematic block diagram of a migration process formigration of a web hosting service from one common service architectureto another common service architecture;

FIG. 22 depicts a schematic block diagram of a migration process formigration of a web hosting service from a virtualized environment to ashared environment for serving multiple clients;

FIG. 23 depicts a schematic block diagram of a migration process formigration of a web hosting service from one web hosting architecture toanother web hosting architecture using a virtual network;

FIG. 24 depicts exemplary request-response cycles for websites duringmigration from a server architecture to a common service architecture;

FIG. 25 depicts a common data store that includes data from variousindividual clients;

FIG. 26 depicts a system for obtaining data from various clients;

FIG. 27 depicts a schematic block diagram of a common servicearchitecture that supports a website hosting service for providing aclient survival analysis;

FIG. 28 depicts a schematic block diagram of a common servicearchitecture that supports a website hosting service for providing 3Dvisualization of a product/service/offering mapping analysis;

FIG. 28A depicts a block diagram of the embodiment of FIG. 28 whereinthe 3D visualization is replaced by a 2D map;

FIG. 29 depicts a schematic block diagram of a common servicearchitecture that supports a website hosting service for providing aclient retention analysis;

FIG. 30 depicts a schematic block diagram of a common servicearchitecture that supports a website hosting service for providing aclient financial impact analysis;

FIG. 31 depicts a schematic block diagram of a common servicearchitecture that supports a website hosting service for facilitatingproduct selection;

FIG. 32 depicts a flowchart illustrating an operational flow foranalyzing client and product purchasing data to produce a purchaseprobability output; and

FIG. 33 depicts a flowchart illustrating an operational flow forpredicting which of a plurality of clients is likely to purchase aproduct or service.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

FIG. 1 illustrates an overview of a common service architecture 100 forproviding web hosting and related services to a plurality of clients.The common service architecture 100 may provide web hosting services tothe plurality of unrelated/unaffiliated clients, such as a client 101through a plurality of servers (e.g. web servers) that may be logicallygrouped into service pools based on common services that may be offeredby the architecture. Exemplary service pools depicted in FIG. 1,including service pool 102, service pool 104 and service pool 108 may besupported by a service pool platform 110 that may include a plurality ofweb servers 103. The web servers 103 may have access to content andother website hosting data related to the hosting clients and hostedwebsites through a shared storage 106. The clients 101 and web hostingagents 118 may access the shared storage 106 and the common servicesthrough an Operational Support System 114 (OSS 114) that may providefunctionalities, such as an initial layer of security, server group loadbalancing, server group access management through distribution of accessrequests to service pools and/or individual servers, and the like.

The service pools may include one or more service-specific groups of webservers 103 for providing various services such as, but not limited to,email, HTML services, website generation, behavior tracking,transactional services, data access (e.g. FTP), media streaming,e-commerce, and the like. The service groups may consist of servers thatserve one of the specific services provided by the web hosting platformof the common service architecture 100. By grouping servers into servicepools and executing a single type of service in a service pool, serverexecution may be made highly efficient with potentially a substantialportion of the executing software residing in fast access memory, suchas cache memory for each processor. A load balancer 112 may be disposedbetween clients 101 and other individuals or systems that interact withthe web hosting platform and the service pools to facilitatedistributing web hosting service requests to each particular servicepool based on the type of request being made. In addition, the loadbalancer 112 may implement algorithms for distributing the request toone or more servers within a particular service pool. For example, arequest for dynamic website generation may be forwarded to a lightlyloaded server in a website generation service pool. The particularservice pool may respond to the request and obtain or deliver necessarydata or information by accessing the shared storage 106 as shown inFIG. 1. The shared storage 106 may implement structured queriessimilarly to a database for retrieving the required information. Theretrieved information may then be forwarded to the particular servicepool; a response may be generated and subsequently passed to the client.For example, the shared storage 106 may store images that may berequired for generating a dynamic website. The website generationservice pool may then use the retrieved data to dynamically create thewebsite and provide a response to the client.

The request may be in the form of a Web Services Description Language(WSDL). WSDL is an XML grammar that describes network services as acollection of communication endpoints that may be capable of exchangingmessages. The WSDL formatted document may include type, message,operation, port type, binding, port, and the like for defining webservices. The binding mechanism may be tied to various protocols andmessage formats including SOAP 1.1, HTTP GET/POST, MIME, or some otherformats, as known in the art.

The request or response data may be in the form of packets. The packetsmay include information such as an IP address of a host, an IP addressof a destination, number of hops, time to live, and the like. Theseparameters are well defined in Internet Protocol versions such as IP v.4and IP v.6.

The load balancer 112 may receive one or more data packets. As describedherein and elsewhere, the load balancer 112 may identify the type ofservices requested by the client. In addition, the load balancer 112 mayimplement an algorithm to forward the request to a server within theservice-specific group.

The WSDL may associate a priority with the request type. For example, ahigher priority may be provided for financial transaction requests withrespect to the request for informational services. The load balancer 112may utilize the information embedded in the data packets to assign apriority to the request. In other embodiments, a criterion offirst-come-first-serve basis may be adopted for the request.

The priority information embedded in the data packets may be utilized todetermine the order of the requests in a priority queue. For example, apriority facility of the load balancer 112 may determine the priorityassociated with a request and rearrange the priority queue beforeidentifying the type of service being requested and therefore to whichservice pool should the request be forwarded.

The service pools may provide inter-operable machine-to-machineinteraction, which may be referred as ‘web services’. The web servicesmay be either simple or complex. Note that this categorization is merelyexemplary and other such categorizations may be possible and areincluded herein. The simple web services pool may include, withoutlimitation, point to point, RPC and messaging based services,non-transactional services (such as simple request followed by aresponse), web security, and the like. Similarly, the complex webservices may include a framework for business-to-business collaborationsand business process management. In addition, this service pool mayinclude a plurality of servers subdivided based on characteristics ofcomplex web services such as multiple parties' interactions,collaboration and work flow, transactions, security, and the like.

The number of servers in each of the service pools may be variable andmay be based on traffic information, type of service within a servicepools (e.g., emails), website generation, transactions, simple requestresponse, scalability of each servers in each service pools, and thelike. Alternatively, the number of servers for receiving the requests ineach of the service pools may be fixed.

The criteria of simple web service and complex web service may be usedto identify the number of servers in each service pool. For example, thenumber of servers provided for simple web service may be 100. Similarly,for a complex web service, the number may be 300. These servers may beequally distributed among various service categories. Alternatively,these servers may be equally distributed among different categories ofsimple web services.

The service pool may include services for indexing traffic data,thumbnails, and other information about web sites. A catalogue servicethat may provide access to product data, product description, productcomparison, electronic commerce and the like.

Similarly the service pool may include authentication service for theclients 101 (e.g. web hosting subscribers) and the agents 118 that mayenable access to other services. The authentication services may beassociated with transaction services that may provide billing andaccounting applications for conducting financial transactions for theclients and the agents.

An informational service may enable businesses, researchers, dataanalysts, and developers to easily and cost-effectively process vastamounts of data. The service pool may include a payment service that mayallow the clients and the agents 118 to make financial transactions formaking payments for online purchases.

Likewise fulfillment service may enable sellers to ship items to theclients and track information related to its delivery. A simple queueservice may provide a hosted message queue for web applications. Adatabase web service may enable the clients to run queries on structureddata stored in an online common data store. In addition, a virtual cloudservice may create logically isolated set of e-commerce instances to beconnected to an existing network using a VPN connection. Furthermore,hosting services, workflow automation services, product developmentservices in a virtual space, chatting services, project managementservices, virtual meeting services, online repository services, dataexchange services and the like may include in the service pools.

The load balancer 112 facility may facilitate improved web hostingperformance through balancing of service and content requests receivedfrom a plurality of sources. These sources may be dispersedgeographically and may request for services such as, but not limited to,content management, e-commerce, web pages, online repositories, and thelike. Servicing a large number of clients simultaneously presentschallenges to scalability of web service architectures. The commonservice architecture 100 may facilitate simultaneously servicing manyclient users by streamlining requests, to different servers within thepool of services, and thereby ensuring high performance and scalability.

An intelligence facility that may be associated with the load balancer112 may identify the request type of a web service request. Thisidentification may be performed based on the service descriptionprovided in the WSDL. For example, the WSDL may provide a type ofservice element in XML for identifying the type of service.

In addition, the intelligence facility may also determine the specificserver from a service-specific group for forwarding the service request.The service request may be forwarded immediately after the determinationstep.

The intelligence facility may be programmed for parallel execution todetermine the type of services and the allocation of server within thespecific group. Further, the intelligence facility may maintain thestatus of all the servers in a service-specific group. This mayaccelerate the process of allocating servers in a service-specificgroup.

The load balancer 112 may include a security facility. The securityfacility may be embedded inside the load balancer 112 or may be aseparate device. Both the hardware and software enabled securityfeatures may be provided by the load balancer 112. The software enabledsecurity features may provide certificate generation, validation,content filtering, and the like. For example, a financial transactionrequest may include a verification certificate, which may be verifiedbefore commencing with the transaction. Similarly, a hardware securitymodule may include IP filtering, secure crypto-processor, and the like.

In addition, the security facility may use Hypertext Transfer ProtocolSecure (HTTPS), which may provide encryption and secure identificationof service requests.

The load balancer 112 may balance the request received for the pluralityof clients using network load balancing (NLB) mechanism or componentload balancing mechanism. For example, the NLB mechanism may balanceload by redistributing IP requests among the identified pool ofservices. This may ensure availability. For example, in case any serverfails, the load may be redistributed among the remaining cluster.Further, the load balancer 112 may utilize a unicast mode or a multicastmode using a single network load balancing adapter.

In addition, the NLB mechanism may provide failover and failback using avirtual IP address, directing traffic to a single server, optimizationof servers assigned for a particular service, and synchronization ofdata for a particular pool of service, and the like.

A component load balancing mechanism may allow dynamic load balancingfor various application components. It may be noted that variousservices may include transaction services, tracking services, emailservices, and other such application services. The component loadbalancing mechanism may utilize the services of the application center,which may be entrusted to instantiate components when requests arereceived from either application center. The request for components maybe directly instantiated by the client by executing an ApplicationProgramming Interface (API).

The shared storage 106 may be configured for the plurality of servicepools. Each service pool may require content for servicing a webrequest. The content may be obtained from or delivered to the sharedstorage 106 using a secured access mechanism such as sign onauthentication or secure SQL script and the like. In addition, storageof the content in the shared storage 106 may ensure reduction in therisk of data loss due to server crashes.

The shared storage 106 may be implemented as a standalone database, as adistributed database, or a combination thereof. Further, the sharedstorage 106 database may implement a relational database that may reduceredundancy of data and optimize storage space. Information may be storedin form of tables and views. This may facilitate removal of redundantinformation.

The shared storage 106 may provide secured access to the service pools.An administrator may write SQL scripts for security verification. Thesescripts, when executed, may facilitate access to the shared storage 106.Alternatively, the server may be programmed to generate automatedscripts that may provide authenticated access to the shared storage 106.

The shared storage 106 may be a distributed database. The disturbeddatabase may facilitate transaction management, incremental storage.Further, the distributed database may facilitate reduction incommunication overheads, increase in performance, and enhancement inreliability and availability of the shared storage 106. Consequently,this may increase performance by introducing parallel execution ofqueries. In addition, horizontal fragmentation, vertical fragmentationor fixed fragmentation may allow faster execution of queries. Variousalgorithms for concurrency control may also be provided to overcomesimultaneous access of various data.

The shared storage 106 may be configured to enable a backup of storeddata. In addition, an API may be provided for analyzing performance ofthe shared storage 106. This process is referred to as ‘Tuning’. Tuningthe shared storage 106 may enhance performance, improve data integrity,and facilitate fast execution of queries and other parameters in theshared storage 106. The API may allow recovery of the crashed sharedstorage 106. In order to avoid frequent crashes, the shared storage 106may be replicated; this may provide uninterrupted access to stored dataeven during crashes.

The shared storage 106 may be implemented as a data warehouse and mayincorporate an API for invoking analytical services, graphs and thelike. For example, the informational service for a cellular operator maybe stored in a service-specific group ‘informational services’. Thecellular operator may be interested in identifying relevant areas ofoperation. Such a request may be forwarded to the service-specific groupin the service pools. The service-specific group, entrusted forproviding the response, may access the shared storage 106 using the API,and may generate a required response for the request. The shared storage106 may be configured as a data warehouse.

The shared storage 106 may be implemented as a plurality of data marts.These data marts may be dispersed in different geographical regions andmay be integrated with each other to form a data warehouse, as known inthe art.

A security access level may exist that allows direct execution of Ad hocqueries to the shared storage 106 thereby allowing submission of anative request to the shared storage 106. Although such access may havea negative impact on the shared storage 106 as it may increase itsvulnerability to crashes, certain situations may best be served byallowing controlled execution of Ad hoc queries such as for managingdata recovery in data warehouses.

FIG. 3 illustrates a schematic block diagram of a common servicearchitecture 100 that may support a website hosting service forproviding a plurality of hosting related services. In the example ofFIG. 3, the services may include exemplary services such as an HTMLservice 302, an email service 304, and a chat service 308 for providingHTML, email, and chat services to one or more of a plurality ofwebsites. The services may be provided to the websites by serversassociated with the common service architecture to facilitate providingeach of the services; the servers may be web servers, or other types ofcomputer-based servers. Exemplary server types may include emailservers, Hyper Text Markup Language (HTML) servers, chat servers, FileTransfer Protocol (FTP) servers, and the like; however, these are onlyrepresentative servers and the services may be provided by these orother servers as are known in the art. The plurality of websites mayinclude unaffiliated/unrelated websites as depicted in FIG. 3 as website310, website 312, and website 314.

The common service architecture 100 may be adapted to provide groupedservices to the websites. Accordingly, in an embodiment, a package ofservices may be created that addresses specific needs, preferences,contractual requirements, subscription policies, and the like of ahosted website. The common service architecture 100 may provide adifferent package of services to at least a plurality of these unrelatedwebsites. Exemplary packages of services as depicted in FIG. 3 mayinclude a service package 320 that may package a three email addressservice and an HTML service, a service package 322 that may package atwo hundred email address service, and service package 324 that maypackage one thousand email address service and a one thousand memberchat service. Although each distinct package is associated with only onewebsite in the embodiment of FIG. 3, a package of services may besubscribed to by one or more websites and a website may subscribe to oneor more packages of services.

The common service architecture 100 may support adapting the servicesfor offering the plurality of packages of services such as for use inthe websites. The services may be adapted by means of one or more of acode library 122 and skins 120. By the use of the skins 120 and the codelibrary 122, the common services architecture 100 may offer differentservice offerings simultaneously. The various different websites 310,312, and 314 may represent clients of the web hosting platform whosubscribe to differentiated packages of services that are offered by thecommon service architecture 100. For example, the website 310 mayrepresent a website for a college student, the website 312 may representa website for a small business, and the website 314 may represent anintranet for a large multi-national company. The services required byeach of the websites may vary based on the type and/or intent of thewebsite. Accordingly, as an alternate example, the website 310 mayrequire two email addresses, the website 312 may require twenty emailaddresses, and the website 314 may require a few thousand emailaddresses. The common service architecture 100 may provide the requiredemail service to each of the websites by adapting a common email serviceof the common service architecture 100 in various ways so that eachwebsite has access to a package of services that meet the needs of thatwebsite.

The service packages 320, 322, and 324 may be provided to individualwebsites from the common service architecture 100 by applying therequirements, preferences, or subscription terms of each website. In anembodiment, the common service architecture 100 may include an emailservice 304 that may provide a different package of the email service toeach of the unaffiliated websites. In an embodiment, the email service304 may be adapted for each of the websites so that each website mayreceive the email service 304 as per the website's hosting subscriptionpackage. In an example, an email service provided by the email service304 may be adapted to appear as a two email service package for thewebsite 310, a twenty email service package for the website 312, and afew thousand email service package for the website 314.

An adapted package of services may be provided for a website. Such anadapted package of services may be dedicated to providing differentiatedservices for the website.

An adapted package of services may be a combination of two or moreservices, such as a combination of HTML and email services or acombination of email and chat services. An adapted package of servicesmay alternatively be a website-specific variation of a common servicearchitecture service. Any combination of services or combination ofadapted services may be provided by the common service architecture 100.The service package 320 may represent an adapted service with an HTMLservice 302 and an email service 304 combined together. The adapted HTMLservice included in service package 320 may offer a certain HTMLcapabilities to the website 310. Similarly, the email service 304 may beadapted to facilitate offering a service package supporting thirty emailaddresses to the website 310 and a different number of email addressesfor use in other service packages such as the service packages 322 and324. Similarly, the service package 324 may represent an adapted emailservice and an adapted chat service combined together. The adapted emailservice may offer a service package supporting one-hundred emailaddresses to the website 314.

FIG. 4 illustrates a schematic block diagram of a common servicearchitecture 100 that may support a website hosting service. The commonservice architecture 100 may provide a plurality of services from aplurality of service pools to a plurality of unrelated/unaffiliatedwebsites, such as website 310, website 312, and website 314 as depictedin FIG. 4. In the example of FIG. 4, the service pools may includeexemplary service pools, such as an HTML service pool 102, an emailservice pool 104, and a chat service pool 108, which may be adapted toprovide a plurality of market-specific services to the websites.

The service pools may include one or more servers such as a plurality ofservers 103 as depicted in FIG. 4. The servers included in the servicepools may be logically grouped on the basis of common web hostingservices. One or more of the service pools may be adapted to provideadapted services 402A through 408B that may be adapted to meet specificneeds of web hosting clients for use in related, unrelated, orunaffiliated hosted websites such as websites 310, 312, and 314. Adaptedservices 402A through 408B may be sources from a common service pool butmay be adapted to be provided to a particular website. In an example,service pool 102 may provide a common HTML service that may be adapteddifferently to serve different websites. Service pool 102 may adapt thecommon HTML service to provide adapted service 402A for website 310 andmay provide the common HTML service adapted differently as adaptedservice 402B for website 312. Similarly to this example, adaptedservices 404A, 404B, and 404C may be adapted differently from a commonemail service that is provided by the servers associated with servicepool 104. Likewise adapted services 408A and 408B may be adapteddifferently from a common chat service that is provided by the serversassociated with service pool 108.

The service pools may include one or more service-specific groups ofservers for providing various services such as, but not limited to,email, HTML services, website generation, behavior tracking,transactional services, data access (e.g. FTP), media streaming,e-commerce, and the like. Each service pool may consist of servers thatprovide one web hosting service provided by the common servicearchitecture 100. Each service pool may provide a different service(e.g. service pool 102 may provide an HTML service and service pool 104may provide an email service). By grouping servers into the servicepools and executing a single type of service on the servers of aparticular service pool, server execution may be highly efficient withpotentially a substantial portion of the executing software residing infast access memory, such as cache memory for each processor. This mayimprove website performance, reduce the number of servers required,support massive scalability of web hosting subscribers, and the like.

The service pools may provide inter-operable machine-to-machineinteraction, which may be referred as ‘web services’. The web servicesmay be either simple or complex. The simple web services pool mayinclude, without limitation, point-to-point, RPC and messaging basedservices, non-transactional services (such as simple request followed bya response), web security, and the like. The complex web services mayinclude a framework for business-to-business collaborations and businessprocess management. In addition, this service pool may include aplurality of web servers subdivided based on the characteristics ofcomplex web services such as multiple parties' interactions,collaboration and work flow, transactions, security, and the like.

The number of servers in each of the service pools may be variable andmay be based on traffic information, type of service within a servicepools (e.g., emails), website generation, transactions, simple requestresponse, scalability of each server, and the like. Alternatively, thenumber of servers for receiving a web hosting request (e.g. accessingwebsite content) in each of the service pools may be fixed, although thefixed number for the service pool 102 may be different than the fixednumber for the service pool 104.

The common service architecture 100 may include a plurality of servers103 arranged in service pools (e.g. the service pools 102, 104 and 108)that facilitate offering packages of services to clients who may desireto have their websites hosted. A need may exist for providing acustomized package of services to a website hosting architecture client.Accordingly, service packages that address specific needs of the hostedwebsites may be created.

The common service architecture 100 may facilitate adapting commonservices handled by the servers in the service pools to providedifferent packages of services. The common services may be embodied asintegrated software running on one or more of the service pool serversand capable of adapting services to needs of the client. Alternatively,the common services may be embodied as separate servers such as loadbalance servers 112 and/or code library 122 servers and the like. In anexample, the common services may adapt a common email service associatedwith service pool 104 so that a website may receive an email servicepackage as per the terms of a client's web hosting subscription with thecommon service architecture 100. Examples of adaptation of services mayinclude the skins 120 and the code library 122 and the like. Adapteddifferent service packages may include a combination of two or moreservices, such as a combination of HTML and email services or acombination of email and chat services. An adapted package of servicesmay alternatively be a website-specific variation of a single commonservice architecture service (e.g. two variations of an email service).

FIG. 5 illustrates a schematic block diagram of a website hostingarchitecture that may comprise a common service architecture 100 forsupporting a web hosting service. The website hosting architecture mayprovide a plurality of services to a plurality of unrelated/unaffiliatedwebsites. A plurality of services available from the website hostingarchitecture may be configured to be deployed to serve the websites. Inthe example of FIG. 5, the service may include exemplary services suchas an HTML service 102, an email service 104, and a chat service 108.The website hosting architecture may further include a common data store106 that may maintain data for a plurality of unrelated/unaffiliatedwebsites. A deployed service may extract from the common data store 106data related to serving a website. Data related to serving a website inthe common data store 106 may be logically separated so that eachdeployed service may access data that is related to a specific website.In the example of FIG. 5, website data 310A may be related to website310 and it may not be related to website 312 and 314. Similarrelationships among website data 312A, 314A and the websites may beunderstood. The website data may be extracted from a shared datastructure 330 that may be accessible through the shared storage 106,which maintains a portion of the website data. The shared storage 106may contain data for at least the plurality of websites. As notedherein, the at least a plurality of websites may be unrelated orunaffiliated. Alternatively, at least a portion of the websites may berelated/affiliated, such as if the portion of websites is owned by acommon entity.

Data that is maintained in the common data store 106 may be shared datafor a plurality of websites. Examples of such common data may includedate and time information, content from third parties, content that isdisplayed on a first website that is sourced from a second website, andthe like.

Further in the example of FIG. 5, each service may require access towebsite data for servicing a web request. The website data may beobtained from or delivered to the shared storage 106 using a securedaccess mechanism such as sign on authentication or secure SQL script andthe like. The shared storage 106 may provide secured access to theservices. An administrator may write SQL scripts for securityverification. The scripts, when executed, may facilitate access to theshared storage 106. The server may be programmed to generate automatedscripts that may provide authenticated access to the shared storage 106.

In addition, if the common data store 106 is accessible to a pluralityof servers, storage of the website data in the shared storage 106 mayensure reduction in the risk of data loss due to server crashes.

The shared storage 106 may be implemented as a standalone database, as adistributed database, a virtual database, a flat file system,cloud-based storage, grid-based storage, combinations thereof, and thelike. Further, an underlying database of the shared storage 106 mayimplement a relational database that may reduce redundancy of data andoptimize storage space. Information may be stored in the form of tablesand views. This may facilitate removal of redundant information.

The shared storage 106 may be a distributed database. The distributeddatabase may facilitate transaction management and incremental storage.Further, the distributed database may facilitate reduction incommunication overheads, increase in performance, and enhancement inreliability and availability of the shared storage 106. Consequently,this may increase performance by introducing parallel execution ofqueries. In addition, horizontal fragmentation, vertical fragmentationor fixed fragmentation may allow faster execution of queries. Variousalgorithms for concurrency control may also be provided to overcomesimultaneous access of various data.

FIG. 6 depicts a schematic block diagram of a common servicearchitecture 100 that may support a website hosting service forproviding a plurality of services from a plurality of service pools. Theservice pools may be distributed across a plurality of servers so that aportion of these servers that may be associated with a first servicepool may also be associated with a second service pool, thereby sharinga server between two service pools. These servers may be physicalservers, virtual servers, web servers, cloud-computing based servers,grid-computing based servers, or any combination thereof. In the exampleof FIG. 6, the service pools may include exemplary service pools, suchas an HTML service pool 102, an email service pool 104, and a chatservice pool 108. The plurality of services may be provided by someservers that provide an overlapping set of services from a plurality ofservice pools and by other servers that are each dedicated to a specificservice pool. The services may be provided to a plurality ofunrelated/unaffiliated websites as depicted by website 310, website 312,and website 314. The plurality of services may include various websiterelated services, such as email services, Hyper Text Markup Language(HTML) services, chat services, File Transfer Protocol (FTP) services,and the like. One or more of the service pools may be adapted tocontribute adapted services as depicted by elements 402A through 408B todistinct websites. An adapted service 402A that includes an emailservice from service pool 102 may be provided to a website 310 byadapting a common email service of the common service architecture 100in a way that the need of the website may be met by subscribing to theadapted email service. Likewise that same common email service may beadapted and provided as adapted email service 402B for website 312.

One or more service pools may be distributed across the servers. In theexample of FIG. 6, some servers, such as a server 103A may be adapted toprovide an overlapping service set in order to facilitate flexibleallocation of resources from more than one service pool. For example,when dedicated email servers in the email service pool 104, areservicing to full capacity, the server 103A that also services the HTMLservice pool 102 may serve a request for an email service. One or moreservers may be adapted to provide an overlapping service set. Anexemplary overlapping service set provided by a server may include emailservices, HTML services, chat services, and other services generallyassociated with website hosting. Various combinations of services may beconfigured on a server to form an overlapping service set. Although theexample of FIG. 6 depicts a server 103A providing services from twodifferent service pools, the server 103A may, in an alternativeembodiment, provide services from three or more service pools. Inanother example of FIG. 6, some servers, such as a server 103B may beconfigured outside any service pool to facilitate flexible allocation ofresources from more than one service pool. For example, the server 103Bmay provide services to any of the service pools such as service pool104 and service pool 108. One or more servers may be adapted to providean services from outside a service pool.

Each of the websites may be serviced by any of the servers in the commonservice architecture 100. The service pools in FIG. 6 may be understoodto include any of the plurality of services described herein, such asemail services, HTML services, chat services, web designing services,ecommerce services, and the like, which are supported by the commonservice architecture 100. Further, a service subscribed to by a websitemay be handled by any of the servers. The service pools may beconfigured to adapt the services provided by the flexible resourceservers 103 for any of the websites. The service pools may includeservers 103 for providing adapted services to the websites. The servicepools may be provided with differentiated services for the websites.

The components described above and elsewhere herein may be combined invarious ways to form these and other embodiments of the common servicearchitecture 100 for supporting a website hosting architecture.

FIG. 7 depicts a flowchart for a method 700 of website hosting. Themethod 700 may include serving a plurality of website hosting servicesfrom a plurality of service pools, at step 702. Each service pool mayserve one website hosting service. At step 704, the method 700 mayprovide a plurality of servers that may be configurable to serve onewebsite hosting service. Further, the method 700 may include determininga demand for server resources for at least one of the plurality ofservice pools, at step 708. In addition, the method 700 may includedeploying a server from the plurality of servers to serve the onewebsite hosting service served by the at least one of the plurality ofservice pools based on the server demand for the at least one of theplurality of service pools, at step 710.

A service pool may include a plurality of servers each configured toserve the same website hosting service. The method 700 may furtherinclude adapting a website hosting service from at least two of theplurality of service pools to meet website service requirements of aplurality of unrelated websites. The plurality of servers may include acloud computing based server architecture, a grid computing based serverarchitecture, a virtual server based architecture, and the like. Theserver may be configured to support a plurality of virtual servers. Inan embodiment, each virtual server may provide services of one of theplurality of service pools. At least a portion of the plurality ofvirtual servers may provide services from two or more of the pluralityof services pools.

The common service architecture 100 may provide access to web hostingservices through a plurality of properties that may be distinct in look,features, and pricing while tying back to the web hosting platform ofthe common service architecture 100. The web servers 103 may have accessto content through the shared storage 106. The clients may access theweb hosting platform through an interface that may be uniquelyassociated with the property through which they contracted for the webhosting services.

Although the underlying resources and services of the web hostingplatform may be elegantly structured around the service pools, theshared storage 106, and the load balancer 112 as described herein thatmay provide a wide variety of capabilities, performance levels, serviceofferings, and the like, potential clients and agents may prefer to beprovided with web hosting and web service packages that address theirspecific needs and are presented in terms that fit to their expectationsor knowledge sphere. Not only can the web hosting platform supportvarious combinations of services traditionally offered by web hostingproviders, but through a novel concept of skins 120 and a code library122, the web hosting platform may appear as substantially differentofferings simultaneously. By configuring a variety of different lookingweb site portals with the skins 120 and the code library 122 thatprovide various portions of the full services available through theplatform at various prices, it may be made to appear to a client thatthere is a diverse marketplace of web hosting providers to choose among.However, rather than these various different web hosting web sitesrepresenting competitors in the web hosting marketplace, they representdifferentiated packages of services provided by the web hostingplatform.

Through a novel application of the skins 120 and the code library 122 towebsite design and other electronic interface methods (e.g. email, ftp,and the like), the underlying web hosting platform may appear as aconsumer level web hosting platform through a first web site and it mayalso appear as an enterprise level web hosting platform through a secondweb site. Through a third web site it may appear as a low cost webhosting site for college students and through a fourth web site it mayappear as a not-for-profit web hosting site for non-profitorganizations. While the client in each case may gravitate toward theweb hosting site that fits his/her needs or interests, the skins 120 andthe code library 122 may collaborate to seamlessly connect the client tothe underlying web hosting platform, without having to reveal to theclient the substantial sophistication and complexity embodied therein.Once a client has established a web hosting account or otherwisearranged for web hosting through the website of his/her choice, theclient may access many, if not all of the features of the web hostingplatform. However, these features may be presented to the user in a modethat is consistent with the theme of the website through which theyarranged web hosting. In this way, a college student may manage servicesfor a hosted web site using the college student skinned web-site and acorporate IT manager may manage services for an enterprise wide hostedweb domain using an enterprise level skinned web site; yet each maystill be managing the same service (e.g. user access security) in theweb hosting platform without knowing it.

In addition to accessing features of the underlying new web hostingplatform using a consistent branded look and feel each time a particularclient accesses the platform features, this same branded interface mayallow a web hosting client to manage the client's web hosting accountsettings, features, and information. In this way, even when performingaccount administrative tasks (e.g. updating a mailing address of a webhosting account holder) the web hosting client may access his/heraccount through the same branded appearance that he/she used toestablish the web hosting account. Therefore, the multi-brandingcapabilities supported by the skins 120 and the code library 122 mayensure that a web hosting client views every accessible aspect of theweb hosting architecture through a consistent and branded interface.

The skins 120 and the code library 122 may collaborate to provide theuniquely different appearance to the same underlying services. The codelibrary 122 in association with the skins 120 may include code tosupport translation and/or conversion of service control andconfiguration commands between the client-oriented skinned website andthe underlying web hosting platform. The skins 120 in association withthe code library 122 may facilitate presenting the features, services,and the like of the underlying platform to the client in aclient-oriented look and feel that may be consistent with the theme ofthe website through which the client accesses the web hosting platform.

The further description discusses how the skins 120 and the code library122 may provide, individually and in combination this richmulti-branding, co-opetitive external view of the web hosting platformresources and services.

The web hosting platform of the common service architecture 100 may beassociated with the code library 122 and various interface skins thatsupport presenting the platform in a multi-branding environment. Asdepicted in FIG. 1, the load balancer 112 may be coupled to the codelibrary 122 which may include programs, databases, code in variouslanguages, and the like for instantiating user interface themes based ona plurality of skins or website templates associated with the platform.The code library 122 may support themes that are depicted through awebsite, software, applications, databases, e-commerce applications andthe like. A skin may facilitate providing a user interface such as a webpage that may allow a user to indirectly interact with the service poolsand other aspects of the platform, such as for providing various webrelated services.

The code library 122 may reside on one or more servers that may be thesame as or different from the servers in the service pools. The codelibrary 122 may reside in one or more of the service pools, may residein the shared storage 106, or may be distributed across one or moreservers that may be physically separated from each other. The codelibrary 122 may be logically grouped and then distributed across aplurality of servers. In other embodiments, the code library 122 may besegmented according to service types provided by the code library 122and may reside in storage accessible to a plurality of serversassociated with each service type in a separate service pool. Similar tothe services being provided in response to a request for servicedescribed herein, the service pools of the code library 122 may beestablished to provide code library services in response to a requestmade through one of the multi-branding websites. In yet anotherembodiment, a portion of the code library 122 may be integrated in theload balancer 112.

In the context of computing terminology, a ‘skin’ may indicate featuresof a graphical user interface (GUI) that may enable a customizedpresentation or theme of generalized software and/or websites. Thecustomized presentation may facilitate marketing of the web hostingservices provided through the web hosting platform through a websiteintended to suit individual needs (specific look and feel) by drawinguser attention to the specific arrangement of elements in the website.This skinned customization of general website features may facilitatepresenting a different level of detail based on the customizationsupported by the skins 120. The different level of detail that may bepresented can be used to present the same underlying web hostingcapabilities to users with differing objectives. For example, a skin maybe configured to present a different level of detail that may attract anexpert user to make an informed decision as compared to a skinconfigured to attract a novice user.

Software that is amenable to or may facilitate changes in presentation(e.g. according to customization rules) may be referred to as‘skinnable’ software and a customized presentation (e.g. a website)generate from skinnable software may be called a ‘skinned’ website. Aplurality of skins may be associated with skinnable software, so thatthe services of the web hosting platform may be presented in differentforms on different websites for the purpose of providing a custominterface to a user of the web hosting platform.

Skinnable software may provide additional features such as improvedusability, better interface, aesthetically appealing display, changedlook and feel of the features, and rearrangement of the interfaceelements according to user preferences. Skinnable software may supportpresenting to a user who works on different computers executingdifferent operating systems the same look and feel of a web page on thetwo different computers running different operating systems. In this waythe invention may support presenting the same website with the same lookand feel on the two different computers/operating systems (e.g. a PC anda MAC) by applying a unique skin for each of the two environments.

A skin may be used to customize a website that provides access to theweb hosting platform for a potential customer (e.g. a web hostingclient) based on any of the following type of target organization torequest hosting, amount of web space desired, number of employees tointeract with the hosted web service/site, type of web services to behosted, and the like. By way of example, and not limitation, arepresentative of a large organization with several hundred employeesmay prefer a website skinned to show an ‘Offer for Corporate Clients.’

When the skins 120 and the code library 122 are taken into considerationas a collaborative effort to provide customizations of user interfacesto the platform, it may be noted that the underlying architecture of theskinned website may be coded and applied to the code library 122 toconstruct a website according to skin-specific requirements.

An output (e.g. a website providing signup or access to the platform)based on any of the plurality of skins may be implemented by a program,which may be initialized or trigged in coordination with a plurality ofconditions. The conditions may include a trigger received from the loadbalancer 112. In another embodiment, the trigger may be in response to aclient activity. In yet another embodiment, the trigger may be inresponse to pre-defined conditions such as time of day, special holiday,and the like. An example may include providing a skin to the existingwebsite on the occasion of ‘Thanksgiving’ displaying special offers forthat day.

An automated rule may be embedded in the program code implementing sucha skin. Thus, in response to a user action on the website, a functioncall to the code library 122 may instantiate spawning a process in thememory, thereby presenting an appropriate skinned version of a website.In may be noted that the example illustrated above is exemplary andimplementation described in the above example may be cloned in otherapplication software, social networking sites, media players, webbrowsers and customized applications offered for free or sale inaccordance with embodiments of this invention.

Skinning associated with web pages, software applications, socialnetworking sites and the like associated with the service pools may beimplemented with a Model-View-Controller architecture. This may enable aflexible structure for easy customization of a GUI implemented with theskinnable software. In addition, the GUI may remain independent from andindirectly linked to application functionality allowing definition ordesign of a customized skin independent of the underlying functionality.Such customization may be limited to aspects of the GUI that are notdependent on the functionality (e.g. color, language, and the like).However, deep changes in the position and function may be possible inorder to customize the software application and/or web pages.

As described above, the websites for accessing the platform may beskinnable. However, the skinnable features provided by at least theskins 120 and/or the code library 122 of the web hosting platform may beused to customize a web hosting client's websites that are hosted by thecommon service architecture 100. Such skinning of customer websites maybe implemented according to the underlying technology described herein.In one example, skinning may be implemented to allow presentation ofhosted websites to depict major changes to the layout and structure ofthe underlying websites. In other examples, skinning may allow minorchanges such as change in color, background and the like. In yet anotherexample, the amount of customization that may be implemented may bebased on preferences that may be provided by the web hosting client ortracked through a web browser, and the like.

In another example, the platform may host a social networking site. Aplurality of skins may be provided that may allow customization ofpresentation of the social network site. For example, Cascade StyleSheet (CSS) implementation may permit visual changes to the presentationof a client login portion of the social networking site. The use of XMLand XSLT may allow more significant changes to the presented layout ofthe web page of the social networking site.

The code library 122 may be accessible from one or more URLs. Inaddition to facilitating customization of the presentation of websitecontent and services, a skin may determine which combination ofcomponents of the code library 122 is accessible. In an example, a skinmay be used to facilitate reseller agreements by allowing the resellerto present components of the code library 122 in a visual mannerconsistent with the reseller's other offerings. The code library 122 mayinclude a software component for validating a password. Further, thecode library 122 may include a component for redirecting users to adifferent URL (Universal Resource Locator).

In addition to the skinning capabilities described herein, the codelibrary 122 may provide additional website related features that maysupport other manifestations of skinning. One manifestation may occurwhen a specific product or service is offered from a plurality ofdifferent websites. This may allow an on-line retailer to offer aproduct or service from several different websites making it look as ifthere are multiple sources for the product or service. Anothermanifestation is using third parties to resell the product or services.The code library 122 may be organized to provide both types of skinning.The code library 122 may be configured to provide a skin that mayvisualize the web page in tune with the reseller's website therebyallowing the reseller to sell services offered by many vendors in acommon look and feel. In addition, the code library 122 may facilitateproviding a limited set of products or services through a websitepresented according to one skin. Likewise, another, different set ofproducts and/or services offered by the same merchant may be sold from awebsite presented based on a different skin. This may allow the users ofthe code library 122 to define a skin according to their requirements orto assemble a group of services for presentation through a websiteconfigured according to a particular skin based on a servicerequirement. Further, the code library 122 may include various scriptedroutines such as administrative routines to help manage data, databaserelated routines, file/folder routines that allow a person to work withfiles or folders on the server, and the like.

The skins 120 may enable targeting of different categories of webhosting services that may be specific to customers with specific needs.This may include the ability to target affinity groups such as hikers,wind power enthusiasts, and the like. Further, the skins 120 may allowtargeting different levels of consumers such as novices or experts anddifferent decision making patterns. The skins 120 may not process theclient interactions with the websites that are customized based on theskins 120, but may facilitate providing different ways to market theservices and/or products using the same underlying common servicearchitecture 100 through the code library 122. These different skins 120may expose a potential web hosting client to different aspects of theunderlying web hosting technology by enabling packaging the differentservices together.

Various skins of websites providing hosting services may differ mainlyin the amount of storage space, resource flexibility, and monthlybandwidth offered by a given plan that is associated with the skin. Forexample, a skin targeting a client representing individuals and smallbusinesses may facilitate providing a starter plan and a premium plan.The starter plan may provide a single domain name, a single emailaddress, and the like. The prime plan may include unlimited storage andbandwidth, unlimited email accounts, unlimited domain names, unlimitedemail accounts, and the like. The skin may also facilitate providingservices such as website management that may enable a client to create adynamic website, website marketing that may enable a client to generatetraffic to the website, e-commerce solutions including credit cardprocessing, shopping carts and the like that may allow the client tosell items and accept payment, mobile email, and business reviewservices such as RATEPOINT.

In another embodiment, a skin targeting a client representing lesssophisticated entities may facilitate configuring a website that may notoffer any choice to the web hosting client/customer. For example, such awebsite may provide the client with only one plan, limited storage andbandwidth, and the like.

A skin may target a client representing a technology savvy consumer. Theskin may facilitate presenting more technical information about thehosting plan.

A skin may use common design elements with another skin. In otherembodiments, the skin may not use the same interface as any other skin,appearing to be completely independent.

Apart from look and feel and target audience, a skin may also differaccording to a price charged for an underlying product or service.Likewise, a skin may allow selling the same service at different prices.A skin may facilitate creating packages that differ only in thelimitations placed on the use of the underlying technology such asstorage space, resource flexibility, bandwidth, and the like.

Third party skinnable application development may be provided a servicepool that handles access to available utilities and applicationsoftware. On a web page serviced by this service pool, a tabcorresponding to personalization may list skinning software that theuser may download for personalization of web pages and/or other softwareproducts. In this scenario, the code library 122 may track thecustomization implemented by the client with a session ID, using thedownloaded skinning software and may track this personalization in theform of a skin. The tracked skin may be utilized for providingcustomized web interface during future interactions.

In one embodiment, the client may download third party skinning softwareand create the skins 120 using tools and drawing objects provided in theskinning software. The client may submit this skin to the service poolthat may automatically integrate the skin into the interface associatedwith the client.

The plurality of skins may be associated with a plurality of codelibraries. In addition to supporting the customization of presentationsof websites in association with the skins 120 as described herein, theplurality of code libraries may include various functions that may notbe limited to visual presentation of the different skins, such aspresentation of data in RSS feeds, integration of data from multipledatabases, aggregation of results produced by statistical analysis,presentation of forms of subscribing to a service and the like. By wayof example and not as a limitation, the code library 122 may spawn up aspell checker in a text message provided in a particular web page. Inanother example, the code library 122 may be implemented as a functionto pop-up special offers to a visitor after tracking the interest of aclient based on browsing history. These and other examples ofimplementation of specific functions using program code may lead tocategorization of code libraries based on functionality, programminglanguage used for implementation, location of the code library 122(local or distributed across network), type of instantiation, complexityof code, algorithm used for implementing a specific functionality suchas but not limited to quick sort, bubble sort and the like. Thus codelibraries may be categorized based on functionality.

FIG. 1 further illustrates an exemplary embodiment of the code library122 being categorized based on functionality. The code library 122 maybe organized based on presentation library, network library, multimedialibrary, database library, graphics rendering library, mathematicallibrary, and transaction library.

The presentation library may include software components, program code,or Dynamic Link libraries (DLL) for formatting and presentation of webpages. In addition, the presentation library may include program codefor implementation of skin corresponding to websites, arrangement ofelements and graphics, formatting of websites and the like. Thepresentation library may include a software component for generatingrandom passwords. The presentation library may enable the user to adddata to the content being displayed on a website. The presentationlibrary may include a software component for displaying a copyright dateat the bottom of a web page. Further, the presentation library mayfacilitate random display of a series of graphics by the user.

The network library may include a code for linking various URLs, DNS,hyperlinks, and other code libraries distributed across a network, suchas the Internet. The network library may also facilitate communicationservices related to the skins 120 and/or instantiating network servicesuch as chats, emails, maintaining sessions and the like.

Likewise, the multimedia library may facilitate playing of music filesrelated to various formats, including video files, and enablingmultimedia in different skins dynamically on request from otherapplications. In addition, the multimedia library may facilitatestreaming of audio and video files on requirement. For example, when aspecific skin is applied to create a website, the multimedia library maydynamically initiate libraries for spawning flash files for animatingthe website.

The database library may provide integration of data to be obtained fromthe common database to be applied to a skin during implementation. Forexample, the website may include an RSS feed that may allow news to bedisplayed in one implementation of skin of a website. The databaselibrary may include a software component for holding multiple datatransactions in a transaction so that if one fails the whole transactionwill fail. The database library may include a software component forblocking entrance to a part of a site on Saturdays and Sundays. The codelibrary 122 may include a software component for counting how many timesa link and/or graphic has been clicked. The code library 122 may furtherinclude a software component for displaying a small portion from aprevious record accompanied with a couple of dots to indicate that thereis more text beyond what is being shown on the screen.

Similarly, date and time library may allow integration of calendar intothe webpage. For example, in another implementation of a skin, acalendar may be provided on the webpage presenting current time and dateand the due date for expiry of a particular service associated with aservice pool. The data and time library may include a software componentfor displaying date and time. The time displayed is the time of theserver. The date and time library may display the number of viewerscurrently viewing the website. The code library 122 may further allowthe user to display time without the seconds. Moreover, the code library122 may include a software code for displaying a program code withoutexecuting the same.

Graphics rendering library may facilitate presentation of specialeffects on the skin including color, animation, font, picture and thelike so that these may be correctly rendered on the client's device.

Math library may allow integration of mathematical functions into theskins 120 at runtime. For example, the mathematical library may generatea calculator at runtime when another skin is implemented on the client'sdevice. The code library 122 may include ways to add colors to alternaterows of the query results. The math library may also include somebuilt-in functions such as typecasting functions, formatting functions,math functions, and the like. The code library 122 may include asoftware component for a countdown to a particular date with ASP, andthe like. Likewise, the math library may include a hit counter fortracking the usage of a website. The code library 122 may enable aperson to create dynamic image maps with ASP. The code library 122 mayinclude a software component for committing or aborting transactions.

Transaction library may facilitate different types of transactionsassociated with the implementation of the skins 120.

Further, it may be noted that the underlying web pages may be formattedaccording to the program code provided in the skins 120 and mayinstantiate one or more code libraries without deviating from the scopeand spirit of the present invention.

The code library 122 may be implemented using various technologies andprogramming languages as known in the field of computer science.Programming languages such as C#, C++, JAVA, VISUAL BASIC, PYTHON, PHP,VISUAL C++ may be utilized for writing code; these libraries may beimplemented using object oriented methodology for reusability of codeand reducing the implementation by inheritance. Other technologiesincluding COM/DCOM and JAVABEANS may be utilized to produce reusablesoftware components. These components may be configured in a manner tobe able to transact a request independent of the platform and underlyingarchitecture thereby making the virtual platform and languageindependent.

One or more code libraries may be DLL files and may be instantiateddynamically based on requirement. In addition, calls to these DLL filesmay be made by one or more program codes during execution. In anotherimplementation, the program code may identify the location and presenceof the DLL before executing the code.

The code library 122 may be associated with tracking of informationassociated with client actions on a website. The tracking of clientactions may be performed based on cookies or other technologies as knownin the art. In addition, customization of the web pages or othersoftware applications may be performed and information stored with theusername so that at a later stage the same may be analyzed andimplemented as skin for a specific client.

The code library 122 may be dynamically updated once the new version isuploaded. For example, when a new version of the code is uploadedthrough an interface for updating code libraries, the new version mayreplace the older version of the code library 122 and subsequently thenewer version may be integrated with requests received thereafter.

The code library 122 may include a software code for hiding/presentingan ID number on the website. The code library 122 may include a softwarecode for encrypting and storing passwords in ASP, and the like. The codelibrary 122 may also include a software code for forcing the person todownload a file instead of opening the same inside a browser window. Thecode library 122 may include a software code for formatting the date asper the format mm/dd/yyyy. The code library 122 may include a softwarecode for generating passwords.

The code library 122 may also include a program code for providing oneor more security functions. For example, the code library 122implementing security may provide authenticity to a client based oncertificate validation. Likewise in another example, a code may beexecuted in a sandbox model to verify potential to harm the client.

The code library 122 may include a software component for validating apassword. Further, the code library 122 may include a component forredirecting clients to a different URL (Universal Resource Locator).Further, the code library 122 may include various scripted routines suchas administrative routines to help manage data, database relatedroutines, file/folder routines that allow a person to work with files orfolders on the server, and the like.

FIG. 8 depicts a schematic block diagram of a new website hostingplatform that may be associated with common service architecture 100that supports multiple branding. In the example of FIG. 8, the websitehosting platform may provide a plurality of services from the commonservice architecture 100 to a plurality of websites. The services mayinclude exemplary services such as an HTML service 302, an email service304, and a chat service 308. The websites served by the website hostingplatform may be related or unrelated. The services available to beadapted to contribute to a distinct package of services may also includewebsite hosting services, such as website generation services,transactional services, data access (e.g. FTP), media streaming,e-commerce, and the like. Examples of the websites may include a websitefor a college student such as website 310, a website for a smallbusiness such as website 312, and a website for a large multi-nationalcompany such as website 314.

Further, each of the services may be adapted to contribute to a distinctpackage of services for at least a plurality of the websites. Thedistinct package of services may include exemplary service packages,such as service package 320, service package 322, and service package324.

The common service architecture 100 may support adaptation of variousservices for use in hosted websites. For example, the HTML service 302,the email service 304, and the chat service 308 may adapt the commonservice architecture services to facilitate contributing to the packagesof services for the websites. Further, differentiated services may beprovided for the website. Furthermore, examples may include a codelibrary 122, skins 120, and the like. A ‘skin’ may indicate features ofa graphical user interface (GUI) that may enable a customizedpresentation or theme of the websites.

Through the skins 120 and the code library 122, the new web hostingcommon service architecture 100 may appear differently in differentmarketing websites. In an example, the web hosting services may appearas a consumer level web hosting platform through a first website and itmay also appear as an enterprise-level web hosting platform through asecond website. Through a third website it may appear as a low-cost webhosting site for college students and through a fourth website it mayappear as a not-for profit web hosting site for non-profitorganizations. A user in each case may gravitate toward the web hostingsite that fits his needs or interests. The skins 120 and the codelibrary 122 may collaborate to seamlessly connect the user to theunderlying common service architecture 100 without having to reveal tothe user the substantial sophistication and complexity embodied therein.Once a client has established a web hosting account or otherwisearranged for web hosting through the website of his/her choice, the usermay access many, if not all features of the common service architecture100 through the market-specific offering through which the client signedup for website hosting. However, these features may be presented to theuser in an interface that may be consistent with the theme (e.g.market-specific offering) of the website through which they arranged theweb hosting. In this way, a college student may manage services for ahosted website using the college student skinned website and a corporateIT manager may manage services for an enterprise-wide hosted web domainusing an enterprise level skinned website; yet, each may still bemanaging the same underlying common service (e.g. user access security)in the web hosting platform without knowing it.

Further, the web hosting service may be marketed through one or moremarketing websites. At least a plurality of marketing websites asdepicted in FIG. 8 may present the web hosting services in differentmarket-specific offerings. In an example marketing website 810 maypresent sports-management specific web hosting offerings, marketingwebsite 812 may present religion-focused web hosting offerings,marketing website 814 may present the web hosting platform asstudent-friendly service offerings, and marketing website 818 maypresent the web hosting platform services as would be attractive to acorporate IT manager. Although specific marketing websites are depictedas being associated with specific service packages, any service packagethat may be served by the common service architecture may be offeredthrough any market-specific marketing website. These customizedmarketing presentations of the common service architecture web hostingservices may facilitate marketing of the web hosting services to suitindividual needs (specific look and feel) by drawing user attention tovisual and auditory elements in a marketing website. Further, the skins120 of the common service architecture 100 may not directly processclient interactions with the marketing websites, but alternatively mayfacilitate provisioning of different ways to market the web hostingservices that are based on common services of the underlying commonservice architecture 100; client interactions may be processed throughthe code library 122. The plurality of services of the common servicearchitecture 100 may also facilitate provisioning services such as:website management that may enable a client to create a dynamic website;website marketing that may enable a client to generate traffic to thewebsite; e-commerce solutions including credit card processing; shoppingcarts; and the like that may allow the client to sell goods and servicesand to accept payment, mobile email, business review services (e.g.RATEPOINT), and the like.

The market specific offerings may include different brands for theofferings. The web hosting platform may enable web hosting clients tomaintain a branded interface for having a look and feel each time theclient may access the web hosting platform features. The brandedinterface may allow the web hosting client to manage web hosting accountsettings, features, information, and the like related to the client'sweb hosting subscription account with the platform. In this way, evenwhen the client is performing account administrative tasks (e.g.updating a mailing address of a web hosting account holder), the clientmay access his/her account through the same branded appearance thathe/she used to establish the web hosting account. Therefore, themulti-branding capabilities (e.g. skins 120 and the code library 122)may ensure that a web hosting user may view every accessible aspect ofthe web hosting architecture through a consistent and branded interface.

The market specific offerings may include different messages for theofferings. The web hosting platform may provide different messages forthe different services provided by the web hosting platform. Themessages may include advertisements, announcements, and the like, whichmay be displayed on the websites.

The market specific offerings may include different service terms andconditions for the offerings. The web hosting platform may ask webhosting clients to agree to a few terms and conditions such asprohibiting online gambling, unsolicited e-mailing, and the like. In anexample, the web hosting platform may strongly react to any use orattempted use of an Internet account or computer without the owner'sauthorization. The web hosting platform may suspend or cancel a client'saccess to any or all services that may be provided by the web hostingplatform when it is found that the account has been inappropriatelyused. For example, if a web hosting client indulges in online gambling,unsolicited e-mailing, copyright infringement activities, and the like,the services provided to such a client may be terminated by the webhosting platform even if the clients have the right to the contentprovided by them.

The web hosting platform may provide different pricing structures forthe offerings. The web hosting platform may provide a variety of websiteportals with the skins 120 and the code library 122 that may providevarious portions of the full services available through the platform atvarious prices. The website portals may be different looking and it maybe made to appear to a user that there is a diverse marketplace withvarious web hosting providers to choose from. The web hosting websitesmay represent differentiated packages of services provided by the webhosting platform. For example, the web hosting platform may providedifferent pricing structures for a same service that may be availed by astudent and a company manager.

The common service architecture 100 may include providing the OSS 114 tofacilitate supporting clients who may need help in web hosting-relatedactivities associated with the architecture. The OSS 114 may facilitatemanagement of various processes, such as, but not limited to, requestprocessing, monitoring of web traffic, inventory management,provisioning services, configuring network components, fault management,and the like. Provisioning may include the process of preparing acomputing environment to provide (new) services to its web hostingclients. The OSS 114 may support provisioning by allowing an agent toaccess secure and non-secure aspects of the platform to help a client oran agent with the addition of a service or a process to the client's webhosting account. For example, the operational support staff (e.g. agent)may upgrade a client's web hosting plan using the OSS 114 in real time.Alternatively, in another example, the agent may block the access of aparticular client to the web hosting platform for failing to comply withthe accepted terms and conditions. The OSS 114 may include anadministrative console that may facilitate modification of client webspace (e.g. moving of files, deleting of files, and the like).Additionally, the OSS 114 may facilitate enabling client-specific faulttolerance, seamless integration of new shared computing or data storageresources, and the like. In addition to these client service-basedcapabilities, the OSS 114 may include business support features that mayfacilitate customer-oriented financial processes, such as taking orders,processing bills, collecting payments, and the like.

The OSS 114 may allow the web hosting platform service provider (or hisdesignated agents and the like) to provide functionality, includingclient relational management, client messaging, client ticketing, clientdashboard for reporting, and operational management, billing, and thelike. In an embodiment, the OSS 114 may include features andcapabilities that facilitate business management, service management,network management, and the like. As described herein and elsewhere, thebusiness management features associated with the OSS 114 may facilitateproviding operational information to operational staff associated withnew hosting platform. This may include information related to clients,hosting plans, current status, and the like. Likewise, OSS-basedbusiness management features may include applications related tocalendaring, collaboration, billing, administration, and the like formanaging the business and other related services associated with theclient.

Service management may be defined as a collection of informationtechnology capabilities that make the business processes functional. TheOSS 114 may facilitate service management of various informationtechnology and related processes associated with high quality servicingof the new web hosting platform. For example, the OSS 114 may facilitateservice management of service level agreements with the clients that mayinclude, for example, minimum uptime availability of the hosted site,timely access to bandwidth, resources, email performance, and the like.For example, email communication may be bound by a service levelagreement that may define the time within which the email will bereceived by the recipient under normal circumstances. The OSS 114 mayallow an agent to examine email performance against the service levelagreement both periodically or on an ad-hoc basis to help with clientmanagement. Because the OSS 114 may allow an agent to examine aplurality of clients' accounts, the agent may be able to quicklydetermine if a range of clients email performance is achieving aservice-level agreement. In another example, the service level agreementmay be with respect to the response time of an application. In thisregard, the web hosting platform may record various activities that maybe accessed through the OSS 114 for helping an agent to ensurecompliance with the service-level agreement. Other service managementfunctions may include, but not limited to, customer care, servicedevelopment and operation, quality of service, and accounting.

The common service architecture 100 may include a network managementcapability that may be associated with the OSS 114. The networkmanagement capabilities accessible through the OSS 114 may include,without limitation, authorization, configuration management, faultmanagement, security management, performance management, resourcemanagement, route analysis, accounting management, and the like. Withrespect to network management, various hardware and software servicesrelated to a client account, a third-party service, a service-levelagreement, and the like may be configured by an agent using the OSS 114.For example, a fault tolerance software service may monitor otherservices running in the OSS 114 to record any occurrence of a fault.Network management data may be collected using agents, sniffers, realtime monitoring, and synthetic monitoring, and may be utilized fornetwork planning and maintenance.

The OSS 114 may provide different access methods for supporting networkmanagement such as SNMP, command-line interface, custom XML, windowmanagement instrumentation, transaction language, CORBA, NETCONF, javamanagement extensions, and the like. The OSS 114 may support managingnetworks that allow integration of new network components withoutreconfiguring the network. Additionally, the OSS-based networkmanagement capabilities may facilitate integration of heterogeneousnetwork components into the network; these heterogeneous components mayinteract with each other to collect data related to management of thenetwork. For example, a router in the platform may be managed by the OSS114 for filtering IP address on pre-defined criteria and theheterogeneous components may collect the IP addresses presented, thefiltered addresses, and the filter criteria in real time.

The OSS 114 may be a centralized service located at a single location orit may be distributed following a distributed model of computing. Whileit may at first appear easy to manage such a service from a singlelocation, there may be issues related to scalability of the managementof the network, and the like. Managing the network or operations from asingle location may increase load on the OSS 114 due to factors such aslack of flexibility, reconfiguration, and the like. For example, changesin static topology may be introduced at the management level andintroduced in the network at the operational level. Since faultmanagement is usually related to the static topology of the network,there may be issues related to the performance of the network in case ofa fault. Therefore, in another aspect of the invention, a distributedOSS model may be implemented. Following a distributed model forimplementing operational support services, various heterogeneousresources of the platform may be integrated using distributed computingtechnologies. For example, Common Object Request Broker Architecture(CORBA) may be utilized for integrating distributed services of the OSS114 in a distributed framework. Likewise, Web services may be integratedwith the OSS 114 in a distributed environment. To this end, UDDI andWSDL may facilitate the implementation of various services.Additionally, the OSS 114 may be implemented using Enterprise Java Beans(EJB) or other technologies such as Remote Method Innovation (RMI),JavaBeans, and the like. It may be noted that architecture forimplementing various services such as business management, servicemanagement, network management, and other management service may vary indesign and implementation according to the technology for enablement ofthe OSS 114 in a distributed environment.

The OSS 114 (or portions thereof) may operate on a cloud computingenvironment. The cloud may provide an interface for management ofservices related to business management, network management, servicemanagement, and the like. In this scenario, the cloud may facilitatelocation-free access with a freedom to the administrator to manageservices from one or more locations.

The OSS 114 may be coupled to any module of the common servicearchitecture 100 including, for example, the load balancer 112 module.The load balancer 112 module may receive requests from the agents 118that need to be communicated to a particular services pool. Depending onthe implementation of the OSS 114, such a request may appear to the loadbalancer 112 as being received directly from the cloud computingenvironment.

The OSS 114 may facilitate management of an affiliate management network138, third-party services 128 that may be coupled to the web hostingplatform through the cloud, and access the shared storage 106 forretrieving client information for accomplishing requests by businessmanagement, service management, network management, and the like.

Customer Relationship Management (CRM) may be an integral part ofmaintaining good customer relationship. The OSS 114 may be connected toa CRM workflow 124 and the client information aggregated at the CRMworkflow 124 may be analyzed by the OSS 124 for creating better clientmanagement metrics. In this aspect, various services associated with theOSS 114 namely business management, network management, servicemanagement, and the like, may be utilized alone or in combination withthe CRM workflow 124 for better client management. Further, the OSS 114may be integrated to include the CRM workflow 124 for bettercoordination and management of customers. Reseller and otherintermediaries in the value chain may also be managed through the CRMworkflow 124. For example, a service ticket related to a reseller may beprocessed at higher priority than a service ticket for one of theclients. In another example, a service ticket generated for the resellermay be processed at a specified service location that may have localtraining specific to supporting resellers.

The OSS 114 may be coupled to the skins 120 and the code library 122functionality described herein that may facilitate maintaining a lookand feel throughout a client's overall web hosting experience. In thisaspect, the administrator of the web hosting platform may integrate theskins 120 and the code library 122 based on the subscription plan. TheOSS 114 may allow the administrator to append the look and feelcomponents into the website on request. To facilitate a consistent lookand feel of the OSS 114, the platform may record various userinteraction parameters, such as the alignment text on a client device,the size and location of graphics of the client device, the layout,color combination, and the like, as per client preferences. Look andfeel information, such as the recorded parameters and skinconfigurations associated with a client web hosting account may becorrelated with the client's hosting plan information and may be storedin the database. An agent may use the OSS 114 to set up a feature torecord the client interactions to be stored in the shared storage 106.Alternatively, client interactions associated with the OSS 114 may bestored in the shared storage 114, an external database, both, and thelike.

The OSS 114 may record information relating to client interaction thatmay include device type (for example, the client may use differentdevices at different times or locations). Accordingly, the OSS 114 mayutilize algorithms for identifying the best interface for a particularclient based on the information, such as device, location, and contentto be rendered. The rendering of an OSS client interface on a particulardevice may be based on the identification of the device (e.g. by theskin functionality described herein), the identity of the client to theOSS 114, the identified client preference information stored in theshared storage 106, the hosting plan and/or the brand identity of theweb hosting subscribed to by the client, and the like.

By working cooperatively with the skins 120 and the code library 122described herein, the OSS 114 may accommodate multiple front-endrepresentations of common OSS and data. The front-end representationsmay be consistent with the brand of the web hosting that the client hassubscribed to.

The OSS 114 may transcend traditional technology by incorporatingbilling and reporting functionality; the business management services ofthe OSS 114 may be entrusted with the task of presenting consolidatedaccess to billing information, usage information, traffic patterns, datausage, and the like. In an embodiment, this information may be appliedto an analysis of a web hosting service agreement associated with theservice management part of the OSS 114 to help reduce costs, identifyfuture business needs, allow a web hosting client to better serve itsclients, and the like.

The OSS 114 may provide web hosting software that may be deployed acrossa plurality of platforms, including UNIX, Linux, Windows, Mac OS, andthe like. The web hosting software may maintain the same look and feelacross the plurality of platforms. The web hosting software may bepackaged with a security certificate that may enable a software functionfor a client having adequate rights. Likewise, a security facility maybe integrated within the OSS 114 that may authenticate a client.

An automated software process that communicates with the OSS 114 may bereferred as a particular embodiment of an agent as described herein. Anyagent (automated or human) interacting with the OSS 114 may request aplurality of services which may be constrained and/or defined inassociation with the agent's set of permissions related to the OSS 114,the common service architecture 100, and the like. Different agents maybe categorized into a permission category or level based on theirpermissions. Permission levels may include, but are not limited to, anadministrator, having the largest set of permissions; a moderator, witha reduced set of permissions; a web hosting client: and a client of aweb hosting client with the least set of permissions. The OSS 114 maymaintain an access control list for each agent listing the permissionsassigned to them. The set of permissions associated with the agent maybe examined when an agent logs on, and the OSS 114 may limit theservices available to the agent. The set of permissions may also beexamined when an agent requests a particular service from the OSS 114.

The OSS 114 may implement different kinds of security, includingpassword-based access, digital certificates, encryption, and the like,for authenticating the agent and the permissions associated with aparticular agent. In embodiments, color may be used to differentiate thedifferent skins of the webpage by a particular permission set associatedwith an agent. Likewise, the permission set may determine the amount ofcustomization that the agent may be authorized to perform on the frontend.

The OSS 114 may include the CRM workflow 124, a client messagingfacility, a client ticketing system, a reporting and operationalmanagement dashboard facility, a billing system, a scaled down consolefor partners, and the like. Although, these facilities may not bedirectly integrated with the client interface, the administrator mayaccess these services to accomplish tasks related to customer servicesthat have been pending or require immediate attention. For example, theadministrator may receive a request about rendering of a particular webpage from a client. The administrator may directly check the ticketassociated with the problem due to its immediate nature.

The capabilities of the OSS 114 may facilitate identifying peak trafficand usage for a web hosting client and initiating actions for handlingan increase in peak traffic, such as by increasing the scalability ofthe service pools, by activating a set of additional servers, or byoperating the service pool at higher utilization levels.

The OSS 114 may utilize widgets to allow customization of web pages,increased performance, security, and reusability of code. A widget maybe a reusable portion of software code that may be incorporated into afront-end presentation by the OSS 114. The OSS 114 may facilitateembedding of widgets into a webpage, a blog, a profile, a social mediasite, and the like. The OSS 114 may also facilitate grouping of aplurality of widgets onto a console.

Using a widget may allow presentation of common web hosting-relatedinformation to appear differently to different agents (e.g. by usingdifferent skins as described herein) without the need to rewrite thesoftware code. The widget may be individually refreshed independently ofa web page, such as for implementing dynamic web browser functionalitywith a reduced platform and network load. A widget may be configured toutilize security protocols to protect client information.

The OSS 114 may utilize a security profile of an agent to identify ifthe agent is permitted to access a specific widget. The OSS 114 may usesecurity profiles to facilitate customizing an agent's display byshowing only those widgets authorized by the agent's set of permissions.

The OSS 114 may provide a widget library. An agent may customize thedisplay by selecting a widget from the widget library. The widgetlibrary may be password protected and the availability of the contentmay be based on the set of permissions for a particular agent.

The OSS 114 may include a widget builder software module that may allowan agent to create a widget with no coding knowledge.

The widget may be implemented using web technologies. These technologiesmay include, but are not limited to, AJAX, JSON, XML, JavaScript, Flash,HTML, and CSS. Widget implementation may be dependent on web browserAPIs.

One or more widgets can be grouped for inclusion into a console. Theconsole may be designed to facilitate a particular operational service,including, but not limited to, transaction management, online payment,ticketing control, request tracking, paperless invoicing, tracking aclient request, IP address tracking, management of IP services,policy-based redirection of services, management of services, to-dolist, and graphical presentation of results, marketing activities,performance information, and other management features related tonetwork hosting management. In embodiments, the console may be a systemconsole, a virtual console, a command line console, terminal emulator,and the like.

The widget may be modified and updated. A single widget may be changedor updated within a console without affecting the other widgets includedin the console. Likewise, a group of widgets may be updated withoutaffecting other widgets in the console.

The widgets may allow the agent complete access to variousclient-related information including, but not limited to, billingreports, client files, emails, and documents. For example, the agent mayselect a widget that displays a warning related to the expiration of thesubscription agreement. The widget may access the billing details of theclient and compare the present data with subscription data to provide anearly warning that may prompt the agent to renew the subscription.

Widgets and consoles may facilitate OSS services that facilitatetracking of data flow inherent in business. For example, the agent mayhave access to a widget that may allow viewing of billing informationand data usage associated with a specific client, such as over a presetperiod of time, and the like.

In another example, organizations may use a hosted web space forcollaborative working such as product development. The progress ofproduct development may require participation from various departments,including R & D, sales, and marketing. In this scenario, a widget may beimplemented to track use of the hosted web space by various corporatefunctions and facilitate depicting various charts to indicate whichcorporate function is a business driver in a research environment.

The OSS 114 may provide access for managing a technical set up of theservice including, but not limited to, location of files, documents,shared resources, location of hosted web pages, and maintainingpermission settings. Furthermore, a customer support front end for theOSS 114 may be integrated with the ticketing and the messaging facilityto generate customized messages and/or reports on behalf of the client.

The reporting facility associated with the OSS 114 may utilize CrystalReports or an ODBC connection to generate custom reports and datagenerated web pages without the need for one-off databases. As describedherein and elsewhere, the reporting facility may be a part of businessmanagement or service management. Additionally, the information may beutilized for performing various analytics on the usage patterns ofvisitors.

The OSS 114 may include a messaging facility, which provides a means forexchanging information or maintaining customer messaging. The messagingfacility may implement various kinds of messaging applications,protocols, and authentication algorithms. For example, the OSS 114 mayinclude an e-mailing service for exchanging information with clients.Likewise, Voice over Internet Protocol (VOIP) may be utilized forimplementing voice services. In another example, RADIUS authenticationmay enhance the implementation of authentication. Other applicationssuch as SMS text messaging, instant messaging, voice, facsimile, andvoice-messaging applications, and the like may be utilized. Themessaging facility may handle a large volume of client messages daily.The messaging facility may also enforce brand identity by providing aunified look and feel to match a client's general web hosting look andfeel. The messaging facility may route the messages into a pool to allowmonitoring of support volume, which may be carried out on abrand-by-brand basis.

The messaging facility associated with the OSS 114 may be provided byone of the service pools and may include server-based e-mail platformssuch as LINUX POSTFIX/SENDMAIL, MERAK mail, and the like. Likewise,third-party email services may be included in the messaging service,such as GMAIL, YAHOO!, HOTMAIL, EVERYONE.NET, and the like.

Service pools facilitating the messaging facility may utilize the sharedstorage 106 for accessing client information. The client information mayallow for integration of a billing facility with the messaging facility.This integration may be facilitated by one or more management service inthe OSS 114 as described above. In one scenario, an automatedstandardized billing report may be integrated with the messagingfacility and provided by the message facility server. Similarly,automation may be utilized by the OSS 114 to provide for one-time orrecurring billing, renewal charges, discounts, and the like.

The messaging facility may include administration of e-mail at the OSS114. The messaging facility may utilize a widget to handleadministration of e-mail. The widget may be utilized to create a uniqueuser-friendly environment to facilitate administration of e-mail. Themessaging facility may also utilize a console containing a plurality ofwidgets to handle administration of e-mail. The messaging facility mayenable a client to add voice offerings to an existing broadband servicewith a manageable expenditure. Additionally, the OSS 114 may incorporateservices that may allow invoicing for both voice and data on a singlebill. This interface may support CDR imports for switches, such asALIANZA, PBXWARE, ASTERISK, TEKELEC, and the like.

The OSS 114 may facilitate providing one bill for multiple web hostingservices; these services may include document management, documentcollaboration, network management, customer management, and the like.The client may pay electronically for using these multiple services.Additionally, the OSS 114 may empower the clients to control all aspectsof their service via web. The OSS 114 may make suggestions to clientsabout the new brands or plans available in the hosting platform toincrease their average revenue and improve retention. In addition,attractive margins on brand and/or plan may be offered to clients forwining their loyalty.

The OSS 114 may include a client support e-mail facility, which may bemanaged by the messaging facility. The client support e-mail facilitymay manage mail or respond to messages from the client 101, the agents118, or other external entities. The client support e-mail facility mayenforce brand identity by ensuring that messages to a client originatefrom an e-mail address associated with the appropriate brand. Likewise,proper terminology for the client's brand may be incorporated by theclient support e-mail facility. All messages may be forwarded to servicepools associated with messaging for creating logs and understandingsupport volume on a brand-by-brand basis.

The messaging facility may manage thousands of messages every day; thesemessages may be analyzed by the corresponding service pools and/or theload balancer 112 facility for creating daily activity reports,authenticating valid address, identifying spam emails, and the like.

The OSS 114 may provide an authentication service, such as anauthentication facility, which may provide real time authentication ofmessages as they are received. The authentication facility may beupdated in real time. Additionally, client profiles may be updateddynamically whenever a client's status or Internet service is changed.

The OSS 114 may include a ticketing system for solving client problems.Client problems may be related to, but are not limited by, web services,queries, product inquiries, and billing inquiries. The client or agentmay also initiate an inquiry via telephone, e-mail, chat, SMS message,instant message, and the like. The ticketing system may allow a customerservice representative to respond to the inquiry by any of: e-mail,telephone, chat, and a client's control panel. The ticketing system willallow a customer service representative to respond in a communicationmeans that may be the same or different from the means used by theclient 101 or an agent to initiate the inquiry. The ticketing system mayfacilitate teams of customer service representatives that may containdifferent levels of support. The ticketing system may provide a means toidentify the best customer service representative to respond to theinquiry. The best customer service representative may be chosen on thebasis of, but is not limited by, location, brand, customer platform,level of support purchased, and length of time since the inquiry wasinitiated. The ticketing system may provide a means for escalating aninquiry to a higher level of customer service representative. Inaddition, the ticketing system may allow a supervisor to identifycompetencies of a customer service representative by monitoring pastperformance. The supervisor may use the ticketing system to identifycompetencies of customer service representatives for specific kinds ofinquiries. The ticketing system may also provide the supervisor a meansto determine how a customer service representative is assigned the nextinquiry. The assignment of the next inquiry may be customized.

The client and agent inquiries in the ticketing facility may be groupedinto message queues. The ticketing facility may coordinate with themessaging facility for analyzing message queues of client and agentinquiries. The message queues may be categorized according to the typeof inquiry. A customer service representative who best fulfills thecriteria for answering an inquiry may be identified by the ticketingfacility and the inquiry may be forwarded to the identified customerservice representative for resolution. The ticketing facility may defythe traditional approach of using round robin distribution of inquiriesamong customer service representatives instead distributing inquiries tocustomer service representatives with known competency of answeringinquiries from a specific area to assure full customer satisfaction.

The ticketing facility may receive an inquiry from the client 101 or anagent via e-mail, SMS, chat, facsimile, telephone, and the like. In onescenario, the client 101 or the agent may use a control panel located ona web page to enter an inquiry. An inquiry entered by the client 101 orthe agent may be queued up for processing, categorized according to typeof ticket, and forwarded to the ticketing facility for processing. Thecontrol panel may include a list box that may allow the client 101 orthe agent to categorize the inquiry which may allow faster processing ofthe inquiry; thus, reducing delays in processing. In another scenario,the client 101 or the agent may be connected to the Internet through amobile device and may submit a ticket through SMS; the OSS 114 mayimplement an SMS processing facility for catering to an inquirysubmitted via SMS. The inquiry may be converted into a universal formatfor processing. Thus, the OSS 114 may provide a format conversionfacility for converting an inquiry to a universal format such as XML orplain text for processing by the ticketing facility.

The ticketing facility may include a response facility for providing aresponse to the client 101 or the agent who submits an inquiry. Theresponse may be automated to support heterogeneous group of devices,including (but not limited to) mobile devices, e-mail, voicemails, SMS,and the like. In one implementation, the response may be in a universalformat. The universal format may facilitate the conversion to a formatthat may be rendered on a device from which the inquiry was sent. Thus,the ticketing facility may identify the format of the inquiry and mayreply to it in the received format. Therefore, multiple devices may beintegrated into the ticketing facility to provide flexibility andscalability to the client 101 or the agent.

A knowledge base of the OSS 114 may be associated with the ticketingfacility, which may include legacy data of a previous inquiry that wasanswered by a customer service representative. An OSS customer servicerepresentative may utilize this repository to identify a possiblesolution to an inquiry by the client 101 or the agent. A top solution(or a set of potential solutions) may be communicated to the client 101or the agent. Of course, the customer service representative'scontextual understanding of the query and the customer servicerepresentative's discretion to suggest the best possible solution may beimportant. Alternatively, ticketing facility may demonstrateintelligence and may implement a complex algorithm to identify a bestpossible solution for customer service representative; this may requirecontacting the client 101 or the agent for more information and passingthe same to the ticketing facility before the ticketing facilitysuggests a solution.

The ticketing facility may communicate with other shared databases orother external repositories; these repositories may include details ofthe client 101 or the agent; inquiries received from different clientsor agents may be analyzed and correlated to identify the client 101 orthe agent initiating an inquiry. In addition, analysis of inquiry mayfacilitate identification of location of the support center handling theticket. Further, response provided to an inquiry may also be analyzedfor assessing the performance of customer service representatives atthat location and for monitoring internal quality.

A ticketing facility may automatically route an inquiry to a customerservice representative based on the level of support purchased by theclient 101 or the agent. For example, premium support may be provided toa client identified as elite; an inquiry received from this client maybe given higher priority and may be attended to first. Similarly, aninquiry may be automatically routed to a customer service representativebased on location, brand, platform, length of time in the queue, and thelike. An inquiry may be distributed to the customer servicerepresentative based on plurality of factors, including (but not limitedby) programmable software, random distribution, logical grouping ofcustomer service representatives, round robin distribution, and thelike. Of course, brand identity may be enforced at all levels incompliance with organizational objectives.

A ticketing facility may facilitate tracking of an issue raised by theclient 101. The issue may contain a problem, a question, a request, anaction, and the like. The issue may be raised in the form of a ticket.The ticketing facility may assign a ticket to an issue reported by theclient 101. The ticket may be placed in a queue until such a time thatit is resolved and/or closed. A unique ticket numbering system may allowfor tracking of a client issue. Once the client issue is addressed bythe provider, the client 101 may terminate or close the correspondingticket through a ticket user interface. The provider may terminate orclose the ticket upon addressing the client issue. The ticketingfacility may automatically terminate or close a ticket when the clientissue is addressed.

The ticketing facility may automatically characterize a client issue bytype of issue. The type of issue may contain a billing question, ahardware problem, a software problem, a request to change a service, atermination request, and the like.

The ticketing facility may provide a means for changing a priority levelassociated with a ticket. The priority level may reflect associatedimportance of a ticket when compared to other tickets. The prioritylevel may also reflect the overall length of time between ticketinitiation and ticket resolution. The ticketing facility may provide auser interface that may allow a client to change the priority level of aticket. Alternatively, the ticketing facility may allow the provider tochange the priority level of a ticket. Further, alternatively, theticketing facility may automatically adjust the priority level of aticket. The automatic adjustment may be based on a set of criteria forticket priority. The set of criteria for ticket priority may contain anamount of time elapsed since a ticket has been opened, a type of issue,an importance or size of client, a level of support that the clientsubscribes to, and the like. The priority level of a ticket may containlow, normal, high, urgent, and the like. The priority level of a ticketmay be raised or lowered at any time.

The ticketing facility may provide a user interface to the administratoror the support staff for viewing a plurality of tickets. The userinterface may allow a provider to view a selection of tickets for aclient, for a specific priority level, for a specific type of issue, andthe like. The ticket may be accessible through a control panel. Thecontrol panel may allow the administrative staff to perform an action ona ticket. The action on a ticket may include create, submit, modify, addnote to, reject, abandon, close, and the like.

The ticketing facility associated with the OSS 114 may be implemented ina multi-tier architecture. Each tier may be associated with a level ofsupport to be provided. The level of support or tier for a ticketgenerated for a service request submitted by a particular client may bebased on a plan associated with that client. A client who has a planthat provides immediate support may be considered a high tier (e.g. tier3) service client, whereas a client with an ‘email only support’ typeplan may be considered a low tier (e.g. tier 1) service client. Aservice tier may be associated with a service request time instead of aclient service plan. In an example, a high priority issue may beallocated to a very high tier (e.g. tier 3 or 4) that may result in aticket that is generated for such a service request being escalated.Service requests may be routed to one or more service locations based onthe service tier associated with the request. In an example, a tier 4service request may be routed to a senior technical support engineer inheadquarters so that he/she can have direct access to key developmentpersonnel to resolve the issue. In another example, a tier 1 servicerequest may initially be routed to an automated service facility thatmay generate automated support responses based on a syntactic and/orkeyword parsing of the service request. In another example, a tier 2request may be routed to a service center in a low cost region and atier 3 request may be routed to a location with highly technicallyqualified support agents.

The OSS 114 may include a billing facility for generating billingdetails for a client. The common service architecture 100 may facilitatebilling that maintains brand identity. The OSS 114 may initiateprocesses for upgrading client usage plans through the administrativeconsole. The administrative console may comprise a GUI that may allowthe client to upgrade or downgrade the web hosting plan. Accordingly,the OSS 114 may change the billing plan of the client.

Agents associated with the OSS 114 may view client billing information.For example, an agent may utilize a control panel to view billingdetails. The agent may choose from a variety of billing-related actions,such as without limitation, modifying, upgrading, discontinuing asubscription, and the like. A billing facility associated with the OSS114 may include access rights that may facilitate determining if theagent is allowed to modify, upgrade, or discontinue the subscription,such as based on a client's subscription agreement. An agent who isallowed to modify a client's subscription may choose to upgrade thesubscription level, may select a different billing schedule, or maymodify another aspect of the client's subscription. In response tosubmission of this request, the agent may be presented with a differentskin that may be associated with the changed client web hostingplan/features.

The OSS 114 may facilitate an agent using the OSS 114 to access a commonview of multiple plans that may be rendered through different skins tothe clients. These plans may be associated with different brand names;however, because they may be implemented in association with the commonservice pools architecture, the OSS agent may view both the brandspecific features and the features that are supported by elements of thecommon service architecture 100. The common service architecture 100 mayfacilitate offering different brand names associated with differenthosting plans while servicing them through an integrated view of theback end architecture elements.

A client who is subscribed to a plan may be automatically associated tothat plan's brand so that an agent viewing the client account may beable to see the client's selected brand through the OSS 114. Thus, theOSS 114 may incorporate an ability to correlate a client or an agentwith the brand name, and plan and automatically render the skins 120corresponding to this brand name to the agent. This may be similar tothe agent being granted proxy access to the client's account through theOSS 114 while retaining advanced access capabilities available to anagent through the OSS 114 as described herein. In addition, an agent mayview plurality of client accounts and may move from one brand view toanother brand view (e.g. one hosting plan to a different plan) fromwithin the interface of the OSS 114.

The OSS 114 may include analytical tools for analyzing different aspectsof the customer relationship management. Additionally, an analyticsfacility 134 may facilitate measurement of different aspects including,but not limited to, customer satisfaction, monthly billing, web traffic,load analysis, new customer addition, and the like.

The OSS 114 may facilitate aggregating data from various sourcesassociated with the common service architecture 100, such as a billingfacility, a support ticketing facility, the CRM workflow 124, and thelike to facilitate viewing the aggregated data by members of web hostingcustomer service groups (e.g. agents). The service groups may includethe administrator of one or more services, support staff, customerservice representatives, some other kinds of support-focusedrepresentatives, agents and the like. In an embodiment, the OSS 114 mayfacilitate transforming and/or formatting aggregated for rendering on anOSS interface for the customer service representative. The format forrendering may be user defined or system defined.

Various statistical analyses may be performed on the aggregated data foranalyzing various parameters associated with various service aspects ofthe web hosting platform. Parameters to be analyzed may include, withoutlimitation web traffic, downtime, ticket queues, support request rate,support request duration, support request escalation, other customerrelationship management parameters, and support requests by brand, byhosting package, by length of service contract, and the like. Providinganalysis of these and other parameters associated with the web hostingplatform may allow an OSS agent to understand a client support requestor problem in context of the factors that most relate to or impact theproblem associated with the request. In an example, a web hostingplatform may service a large number of clients distributed acrossdiverse locations. Each client of the web hosting platform may engage inone or more activities, such as addition of mailbox, upgrade of plan,and the like through a particular web hosting brand. Analysis ofparameters such as association of adding a mailbox through a particularbrand may indicate that a client accessing the web hosting platformthrough that particular brand may be more likely to experience a problemwith adding a mailbox than do clients who access the platform throughanother brand, and that a workaround has proven effective for clients ofthe particular brand. In this way, when the support request is presentedto the agent, the agent may be able to quickly identify the brand andview the analysis associated with that brand to better resolve theclient's support request.

As described herein, the OSS 114 may provide a unified interface to thecustomer service representative (e.g. agent) for managing varioussupport activities that may allow an agent to service a diversity ofbrand-specific clients without necessarily having to access the platformdirectly through the specific brand. Alternatively, the OSS 114 mayfacilitate a user accessing the web hosting platform through the brandin experiencing the same environment as the client 101. In this way,multiple brands may also be managed by a single agent.

The web hosting platform supported by the common service architecture100 may be implemented as service-oriented software architecture thatmay allow the software capabilities to be delivered and consumed as aservice as in known in the art. The various endpoint interfacesassociated with such a software service may be provided as service-basedinterfaces as well. One or more of these endpoint service-basedinterfaces may be associated with a user (e.g. through a device) such asthe customer service representative or agent, a technical specialist, asales specialist, an administrator and the like. Service-based endpointinterfaces may alternatively be some other type of interface, such asmachine, network, or similar programmatic interface. The various OSSinterfaces and endpoints may be synchronized to display the same data,thereby maintaining consistency of the OSS 114 through the web hostingplatform. In another embodiment, data consistency may be associated withand/or based on a specific brand, client, web hosting plan, and thelike.

The OSS 114 may be implemented in any of a large variety of softwareprogramming models, languages, techniques, and the like. One suchexemplary programming model is Object Oriented Programming in which thedata and methods may be isolated from each other. Furthermore, variousprinciples of inheritance, abstraction, and polymorphism may be utilizedin embodiments of the common service architecture 100.

In another implementation, the OSS 114 may be organized as a basearchitecture where the data and services originate, and as a cloud-levelportion that supports cloud computing environments. Additionally, acloud-type network processing architecture may overlay the basearchitecture to provide client support interfaces that may facilitateticketing and other service access for multiple clients with multipleskins. Each client may be engaged in a specific support activity. When alarge number of users are engaged in different support activities, itmay be necessary to support millions of nearly simultaneous supportactivities. The cloud-level portion of the OSS 114 may be operatedwithin a cloud computing environment to support agents performingactivities and/or services across multiple clients and multiple brandsbeing provided from cloud computing resources while ensuring thatchanges made to a specific client may be visible to all service supportrepresentatives throughout the cloud-based OSS embodiment. This mayensure that moderation made to any service with respect to one or moreclients is visible across all aspects of the web hosting platform evenif portions are operating as cloud computing resources. Further, the webhosting platform may be implemented in association with cloud computingthat may facilitate providing support regionally by directing servicerequests through the cloud to an agent that may be local or at leastwithin a similar time zone to the client. In an example, the client maybe located in India and a service request may be routed through thecloud to a service group of agents located in India or the Philippines.However, the service request, and any service ticket or other CRM datagenerated as a result of such a request may be located in any or anumber of locations, including a shared storage 106 associated with theweb hosting platform of the common service architecture 100.Alternatively, a local service support representative may validate alocal service support request and the information associated with therequest may be presented to a technical specialist who may be accessingthe platform through a client device located in a different geographicregion. The same information may be displayed on the interface of theservice support representative and on the technical specialist forconsistency and improved customer service.

As described herein, the service support representative may be able tomanage multiple skins for one or more clients from a unified OSSinterface. This may be beneficial because a client may intentionally usedifferent skins to differentiate access to his hosted web content fordifferent users. One example of such an environment may be based on anorganizational hierarchy associated with the hosted web content. In thisaspect, different users may have different skins. A particular servicesupport representative may support the activities for this web hostingclient by directly supporting the clients associated with the particularweb hosting client. Because different clients may have different accessrights to a web hosted content based on the brand with which they may beassociated, the service support representative may be entrusted with thetask of ensuring that all clients are able to access and/or performactivities for which they have the access rights while providing servicesupport to different users of the web hosting client. To do this, theOSS 114 may facilitate an agent interface that may allow full access toall of a client's features and services even when the agent is servicinga particular client of that web hosting client. Further, in addition tothe service support representatives providing technical support to aclient, the service support representative may be called upon to promotesales (e.g. suggesting that a client upgrade his/her access to the webhosted content to improve a capability related to a support request),provide cross-client support, and facilitate branding of services sothat a brand-specific client does not need to be aware of the presenceof other brands for accessing the same web hosted content.

The OSS 114 may provide different views of the web hosting environmentand the common service architecture 100 to an administrator, a billingrepresentative, a manager, a technical representative, an agent or tosome other person associated with the OSS interface.

The OSS 114 may be implemented on a hardware platform executing softwarethat may support virtualization. Virtualization is generally implementedas a process that executes software independently of the underlyinghardware. Virtualization may be implemented as fully isolated from thehardware, partially isolated from the hardware (e.g. to support somereal-time activity) also known as para-virtualization.

In a virtual environment, each operational service may be associatedwith a separate virtual machine, thereby allowing different technicalrepresentatives to manage, analyze, and control these services inisolation from each other. Alternatively, virtualization may facilitatethe multi-brand capabilities of the common service architecture 100.Virtualization may also be beneficial during migration of hosted contentfrom a third-party web hosting service to the common servicearchitecture 100.

Virtualization may facilitate optimal hardware utilization. Multiplevirtual machines may be executed on a single hardware for increasingoperational efficiency of the common service architecture 100. In anembodiment, the virtual machine may be a system virtual machine or aprocess virtual machine. Various advantages may accrue by implementingvirtualization such as existence of multiple OS environments on a singlecomputer, implementation of an instruction set architecture (ISA),application provisioning, maintenance, high availability, and disasterrecovery.

FIG. 2 illustrates an overview of the architecture of the OSS 114 as alayer that connects to all aspects of the common service architecture100. Through this comprehensive association at the client level,affiliate level, business operation level, physical server pool and datastorage level affords an agent using the OSS 114 to provide clientsupport the opportunity to confidentially access any aspect of theplatform to provide the service. A client who has a support questionabout data security may be serviced by an agent who may access theshared storage 106 as a database manager in order to check databasesecurity features and settings for both the physical data storage andthe logical data storage associated with the client. Many other suchexamples of how the OSS 114 may allow an agent to service a client fromboth the client level interface to the platform and the low level“bottom-up” view of the platform are possible.

Therefore, the OSS 114 layer may allow agents to access secure andnon-secure aspects of the platform. The OSS 114 layer may allow agentsto access the platform like a hosting client. Alternatively, the OSS 114may allow the agents 118 to access the platform independent of thehosting client views or limitations. The OSS 114 layer may also beconnected to CRM workflows. The client information aggregated from a CRMdatabase may be analyzed by the OSS 114 for creating better clientmanagement metrics. In this aspect, various services associated with theOSS 114 namely business management, network management, servicemanagement, and the like may be utilized alone or in combination withthe CRM for better client management.

Further, the OSS 114 may be coupled to the skins 120 and the codelibrary 122. The skins 120 and the code library 122 may facilitatemaintaining a look and feel throughout a client's overall web hostingexperience. In this aspect, the administrator of the web hostingplatform may integrate the skins 120 and the code library 122 based onthe subscription plan. In an embodiment, the OSS 114 may allow theadministrator to append look and feel components into the web site onrequest. The OSS 114 may facilitate management of third-party servicesthat may be coupled to the platform through the cloud, accessing ashared storage 106 for retrieving client information, and foraccomplishing requests by business management, service management,network management, and the like. In an example, the third-partyservices may include payment gateway, advertisement engine, emailservices, ecommerce facilities, and the like. The capabilities of theOSS 114 may facilitate identifying peak traffic and usage for a webhosting client and thereafter, may facilitate initiating actions forhandling an increase in peak traffic, such as by increasing thescalability of the service pools, by activating a set of additionalservers, or by operating the service pool at higher utilization levels.Further, in an embodiment of the invention, the OSS 114 may be coupledto the load balancer 112. The load balancer 112 may receive requestsfrom the OSS 114 agents that need to be communicated to a particularservices pool. Depending on the implementation of the OSS 114, such arequest may appear to the load balancer 112 as being received directlyfrom the cloud computing environment.

Further, the OSS 114 may be coupled to business operations 140. Thebusiness operations 140 may be further associated with an analyticsfacility 134 and an affiliate network 138. The business operations 140may include migration of web service from a traditional platform to thecommon service architecture 100; monitoring of web traffic, accesscontrol, billing, configuration of public and private IP address,bandwidth measurement; and integration of third-party services such aspayment gateways and the like. Further, the aggregated data collectedfrom one or more of these services may be analyzed at the analyticsfacility 134 for assessing the performance of the web hosting platformor one or more services associated with it. Similarly, the affiliatenetwork 138 may be integrated with the business operations 140 forproviding advertisement in the web pages and for generating revenues.

The OSS 114 may further be coupled to the analytics facility 134. Theanalytics facility 134 may provide statistical data about the usertraffic analysis. The analysis may include the traffic growth, thesource of the traffic, information about viewing pattern and loyalty,popular landing and exiting page, and the like.

The OSS 114 may further be coupled to the affiliate network 138. Theaffiliate network 138 may act as an intermediary between websitepublisher and merchants. Affiliate networks may provide links andbanners, program sign-up sheets, payment services, and sales tracking.The affiliate network 138 may provide a program in which the publisherof a website may receive a portion of income for generating leads,traffic, or sales to a merchant website. The publisher may sign up foran affiliate program in order to make more money and may do so byplacing banner or text links on their website.

FIG. 9 illustrates a schematic block diagram of common servicearchitecture 100 that may support a website hosting service which mayprovide a plurality of services to each of a plurality of unrelatedwebsites. As described in FIG. 3, the plurality of hosting services mayinclude exemplary services such as an HTML service 302, an email service304, and a chat service 308 for providing HTML, email, and chat servicesto a plurality of websites. The services may be served to the websitesby servers associated with each of the services; the servers may be webservers. Exemplary server functionality may include email servers, HyperText Markup Language (HTML) servers, chat servers, File TransferProtocol (FTP) servers, and the like; however, these are onlyrepresentative servers and the services may be provided by these orother servers as known in the art. The plurality of websites may includeunaffiliated/unrelated websites as depicted in FIG. 9 such as website A910, website B 912, and website C 914.

Each of the plurality of services may be adapted to contribute to adistinct service package for at least a plurality ofunrelated/unaffiliated websites. Exemplary packages of services mayinclude a service package 320, a service package 322, and a servicepackage 324. For example, the service package 320 may package a fiveemail address service and an HTML service. In another example, theservice package 322 may package a five hundred email address service,and the service package 324 may package two thousand email addressservice and a two thousand member chat service. Although each distinctpackage may be associated with only one website in the embodiment ofFIG. 9, a package of services may be subscribed by one or more websitesand a website may subscribe to one or more packages of services.

The website hosting service provided by the common service architecture100 may be marketed through a plurality of marketing sites, such asmarketing websites, marketing emails, advertisements, electronicpublications, print publications, and the like. The plurality ofmarketing sites may be different looking, with different terms so as tomake it appear to a potential web hosting client that there is a diversemarketplace of web hosting providers to choose from even though theunderlying common service architecture 100 may provide the distinctpackage of services for any of the different looking market specificofferings. The common service architecture 100 may offer differentmarket specific offerings for various packages of services and otherfeatures available from the website hosting service. Exemplary marketspecific offerings may include, but are not limited to, market offering902, market offering 904, and market offering 908.

A customized presentation for each marketing site may facilitatemarketing of the website hosting services provided by the common servicearchitecture 100 through a marketing website that may be intended tosuit individual needs (specific look and feel) by drawing user attentionto, for example a specific arrangement of elements in the marketingwebsite. The customized presentation may be provided to each marketingsite. The skins 120 may or may not process a user's interactions withthe websites, but may facilitate provisioning different ways to marketthe services and/or products using the same underlying common servicearchitecture 100 through the code library. The skins 120 may alsofacilitate the provision of services such as website management that mayenable a client to create a dynamic website, website marketing that mayenable a client to generate traffic to the website, e-commerce solutionsincluding credit card processing, shopping carts, and the like that mayallow the client to sell items and accept payment, mobile email, andbusiness review services.

The market specific offerings may include different brands for theofferings that may maintain a branded interface (e.g. a look and feel)each time a client may access the web hosting platform features, such asthrough an account service user interface. Such a branded interface mayallow the client to manage his/her web hosting account settings,features, and information in an environment that is consistent with thelook and feel of a marketing site through which the web hosting accountwas initiated. In this way, even when the client is performing accountadministrative tasks (e.g. updating a mailing address of a web hostingaccount holder), the client may access his/her account through the samebranded appearance that attracted him/her to the web hosting service.Therefore, the multi-branding capabilities supported by the skins 120and the code library 122 may ensure that a web hosting user may viewevery accessible aspect of the common service architecture 100 through aconsistent and branded interface.

The market specific offerings may include different messages for theofferings. The web hosting platform may provide different messages fordifferent services provided by the web hosting platform. The messagesmay include advertisements, announcements, and the like, which may bedisplayed on the websites. The messages may be directed at certaininterests, such as fantasy sports, hobbies, political agendas, religiouspreferences, and the like. These messages may entice a potential webhosting client to consider the market specific offering as arepresentation of an aspect of the website hosting service that appealsto him/her. A theme associated with such messages may be maintainedthrough the use of skins 120 to generate client account service userinterfaces. In this way, the client can access the sophisticatedcapabilities and features of the common service architecture 100 inmessage-specific interfaces.

The market specific offerings may include different service terms andconditions for the offerings. Different service terms and conditions maybe adjusted based on the client acquisition objective of a marketspecific offering. Terms for a marketing specific offering focusedtoward parents of young children may emphasize safe web browsing habitsand terms that enforce limitations on access to certain website content;thereby preventing a client who agrees to these terms from postingcontent on a hosted website that is inappropriate for young children. Inanother example, terms and conditions for a market specific offeringfocused toward firearms enthusiasts may require compliance with some ofthe National Rifleman's Association membership terms.

Even with these different service terms and conditions, the web hostingplatform may ask potential web hosting clients to agree to a few termsand conditions such as prohibiting online gambling, unsolicitede-mailing, and the like. In an example, the web hosting platform maystrongly react to any use or attempted use of an Internet account orcomputer without the owner's authorization. The web hosting platform maysuspend or cancel a client's access to any or all services that may beprovided by the web hosting platform when it is found that the accounthas been inappropriately used. For example, if a web hosting clientindulges in online gambling, unsolicited e-mailing, copyrightinfringement activities, and the like, the services provided to such acustomer may be terminated by the web hosting platform. The customersmay have the right to the content provided by them.

The web hosting platform may provide different pricing structures forthe different market specific offerings. The web hosting platform mayprovide a variety of service packages via the skins 120 and the codelibrary 122 that may provide access to various portions of the fullrange of adapted services available through the common servicearchitecture 100 at various prices. The web hosting websites mayrepresent differentiated packages of services provided by the webhosting platform. For example, the web hosting platform 100 may marketdifferent pricing structures for a service to a student than for thesame or similar service targeted to a company IT manager.

In the example of FIG. 9, the different market offerings may include oneor more distinct service packages. For example, the market offerings902, 904, and 908 may include the service package 320. The marketofferings 902, 904, and 908 may offer these one or more service packagesto the plurality of unrelated/unaffiliated websites such as website A910, website B 912, and website C 914. The plurality ofunrelated/unaffiliated websites may be configured with agent-basedaccounts. The plurality of unrelated/unaffiliated websites may providethe different market offerings to the agent-based accounts through aplurality of account service user interfaces such as account serviceuser interface 918, account service user interface 920, and accountservice user interface 922. In an example, the websites such as websiteB 912 and website C 914 may be associated with an agent-based accountuser interface 924. The agent-based accounts initiated through aparticular market specific offering may be maintained under a consistentlook and feel associated with the particular market specific offeringwhen presenting account service user interfaces such as 918, 920, and922.

Referring to FIG. 10 a service representative 1002 may need to providesupport to a client for a particular client hosting account. Agents mayinteract with a wide variety of clients, necessitating access to themarket-specific offering associated with a particular client to addresswebsite hosting account questions and support needs. To ensure that thebranding associated with each market specific offering may be carriedthrough to interactions between the client and a platform agent, theagent is provided with information that facilitates providing theappropriate service for the market specific offering associated with theclient. This may ensure that the messages, look-and-feel, terms, andpricing structures associated with the market specific offering linkedto the client website hosting account may be made visible to the agentwhen either is accessing the client website hosting account, such as forservice purposes. While the client may always access the common servicearchitecture 100 through the market-specific offering based service userinterface, an agent may be presented with both the market-specificoffering user interface to view the same information as the client andwith a more generalized user interface that allows the agent to viewother market specific offerings, other service packages, and otherservices of the common service architecture. The operational supportsystem (OSS) 114 of the present invention may further facilitate anagent presenting new or different services or packages of services tothe client through his/her market specific offering by ensuring that theagent has access to information that facilitates providing theappropriate service.

FIG. 10 further illustrates a schematic block diagram of a commonservice architecture 100 that may support a website hosting service. Theweb hosting service may provide a plurality of distinct services to aplurality of websites, such as website 310, website 312, and website314. The websites may be unrelated or unaffiliated. In the example ofFIG. 10, the services may include exemplary services such as an HTMLservice 302, an email service 304, and a chat service 308 for providingHTML, email, and chat services to one or more plurality of websites.

Further, each of the services may be adapted to contribute to a distinctpackage of services for at least a plurality of websites. The distinctpackage of services may include exemplary service packages, such asservice package 320, service package 322, and service package 324.Various services may be adapted for use in the websites. For example,the HTML service 302, the email service 304, and the chat service 308may be adapted for contributing the packages of services to thewebsites. Differentiated services may be dedicated for the website.

The web hosting service may be marketed through one or more marketingwebsites. At least a plurality of marketing websites, which may includeexemplary marketing websites, such as marketing website 810, marketingwebsite 812, marketing website 814, and marketing website 818, maydescribe different market specific offerings for the packages ofservices. Each one of the plurality of marketing websites may offer aplurality of market specific offerings. The plurality of market specificofferings may include exemplary market offerings, such as marketofferings 902, market offering 904, market offering 908, and marketoffering 910.

Further, service representatives supporting a plurality of differentmarket specific offerings may be provided with information facilitatingproviding an appropriate service for a particular market specificoffering. Exemplary service representatives include a servicerepresentative 1002 and a service representative 1004. In an example,the information provided to the service representatives may be obtainedfrom the OSS 114. The information provided to the OSS 114 may beassociated with a service package. The service package may includemetadata that may be available to a service representative through auser interface and may help the service representative to determine whatportion of the services in the service package is associated with themarket specific offering. The services required by each of the websitesmay vary based on the type and/or intent of the website.

Further, the OSS 114 may receive information from more than one servicepackages. For example, the OSS 114 may receive information from theservice package 322 and the service package 324. The servicerepresentatives may serve more than one market offering such as themarket offering 1004 may serve the market offering 908 as well as thewebsite 910.

FIG. 11 illustrates a schematic block diagram of the embodiment of FIG.2 in which a customer relationship management (CRM) system also referredas ‘Operational Support System 114’ or ‘OSS 114’ may enable access todata for client and agent interactions with any component of anunaffiliated web domain hosting, such as the common service architecture100 described herein.

As illustrated in FIG. 11, the OSS 114 may facilitate access to dataassociated with connect to all aspects of the web hosting architectureas an interface or interaction facilitation layer. Through thiscomprehensive association at the client level, affiliate level, businessoperation level, physical server pool, and data storage level, agents118 may provide client support while confidentially accessing any aspectof the web hosting platform. A client 101 who may have a supportquestion about data security may be serviced by an agent 118 who canaccess the common data store 106 similarly to a database manager inorder to check database security features and settings for both thephysical data storage and the logical data storage associated with theclient. Therefore, the OSS 114 may allow the agents 118 to access secureand non-secure aspects of the web hosting platform.

Further, the OSS 114 may allow the agents 118 to access the web hostingplatform like hosting clients 101 to allow the agents 118 to experiencethe web hosting platform just as the client experiences it. However, theOSS 114 may also allow the agents 118 to access the web hosting platformindependent of client-specific views or limitations to broadly provideservices across each element of the web hosting platform 100.

The OSS 114 may facilitate management of third-party services 128 thatmay be coupled to the web hosting platform, such as through a cloudnetworking environment. The OSS 114 may enable access to third partyservices, third-party service data, third-party support interfaces, andthe like that may facilitate an agent 118 of the web hosting platform100 in addressing client 101 problem with a third-party service.

By enabling data access for any component of the platform 100, the OSS114 may facilitate management of the platform 100, such as by providingdata that may be useful in identifying peak traffic and usage for a webhosting client and thereafter, may facilitate initiating actions forhandling an increase in peak traffic, such as increasing the scalabilityof the service pools, activating a set of additional servers, oroperating the service pool at higher utilization levels.

The OSS 114 may be coupled to any facility of the web hostingarchitecture including, for example, a load balancing facility 112. Theload balancing facility 112 may receive requests from the agents 118that may need to be communicated to a particular services pool.

The OSS 114 may also be coupled to the business operations facility 140.The business operations facility 140 may facilitate migration of webservice from a traditional platform to the new architecture; monitoringweb traffic, access control, billing, configuration of public andprivate IP address, bandwidth measurement; and integration ofthird-party services 128, such as payment gateways, overall operationand optimization of service offerings, and the like.

The OSS 114 may allow the agents 118 to provide functionality, includingclient relational management, client messaging, client ticketing, clientdashboard for reporting, and operational management, billing, and thelike. The OSS 114 may include features and capabilities that facilitatebusiness management, service management, network management, and thelike. As described herein and elsewhere, the business managementfeatures associated with the OSS 114 may facilitate providingoperational information to operational staff associated with new hostingplatform. This may include information related to clients, hostingplans, current status, and the like. Likewise, OSS-based businessmanagement features may include applications related to calendaring,collaboration, billing, administration, and the like for managing thebusiness and other services associated with the client.

The affiliate network 138 may act as an intermediary between websitepublisher and merchants. Affiliate networks may provide links andbanners, program sign-up sheets, payment services, and sales tracking.The affiliate network 138 may provide a program in which the publisherof a website may receive a portion of income for generating leads,traffic, or sales to a merchant website. The publisher may sign up foran affiliate program in order to make more money and may do so byplacing banner or text links on the website.

FIG. 12 illustrates a schematic block diagram of an alternate embodimentof the invention of FIG. 11 in which a CRM workflow 124 is configuredwith the OSS 114 to facilitate handling a client problem. As noted forFIG. 11, the OSS 114 may enable access to data for client and agentinteractions with any component of the unaffiliated web domain hosting.

The OSS 114 may be connected to the CRM workflow 124 and the clientinformation aggregated at the CRM workflow 124 may be analyzed by theOSS 114 for creating better client management metrics. In this aspect,various services associated with OSS 114, such as business management,network management, service management, and the like may be utilizedalone or in combination with the CRM workflow 124 for better clientmanagement. Further, the OSS 114 may be integrated to include the CRMworkflow 124 for better coordination and management of customers.Reseller and other intermediaries in the value chain may also be managedthrough the CRM workflow 124. For example, a service ticket related to aReseller may be processed at higher priority than a service ticket forone of the web hosting platform clients. In another example, a serviceticket generated for the Reseller may be processed at a specifiedservice location that may have local training specific to supportingResellers.

Further, the client/agent interactions in the CRM system may beorganized in a workflow for handling a client problem. The workflow maybe a ticketing workflow. The OSS 114 may include a ticketing system forsolving client problems. The client problems may be related to, but notlimited by, web services, queries, product inquiries, and billinginquiries. For example, referring to the CRM workflow 124, a client oragent may initiate an inquiry at step A of the ticketing workflow. Theinquiry may be initiated via telephone, e-mail, chat, SMS message,instant message, and the like. The inquiry entered by the client oragent may be queued up for processing, categorized according to type ofticket, and forwarded to the ticketing facility for processing. Inanother scenario, the client or agent may be connected to the Internetthrough a mobile device and may submit a ticket through short messageservice (SMS). The OSS 114 may implement an SMS processing facility forcatering to an inquiry submitted via SMS. The inquiry may be convertedinto a universal format for processing. Thus, the OSS 114 may provide aformat conversion facility for converting an inquiry to a universalformat such as XML or plain text for processing by the ticketingfacility.

In response to the inquiry, at step B, the ticketing system may allow acustomer service representative to respond to the inquiry by any ofe-mail, telephone, chat, and a client's control panel. The ticketingsystem may allow a customer service representative to respond through acommunication means that may be the same or different from the meansused by the client or agent to initiate the inquiry. Alternatively, theticketing facility may include a response facility for providing aresponse to a client or agent who submits an inquiry. The response maybe automated to support heterogeneous group of devices, including (butnot limited to) mobile devices, e-mail, voicemails, SMS, and the like.In one implementation, the response may be in a universal format. Theuniversal format may facilitate the conversion to a format that can berendered on a device from which the inquiry was sent. Thus, theticketing facility may identify the format of the inquiry and may replyto it in the received format. Therefore, multiple devices can beintegrated into the ticketing facility to provide flexibility andscalability to the client or the agent.

If the customer service representative is unable to answer the clientinquiry, the ticketing system may provide a means for escalating aninquiry to a supervisor at step D. In another scenario, if the client orthe agent is unable to get solution to an inquiry made to the automatedsystem, the ticketing system may send the inquiry to a customer servicerepresentative at step D. The ticketing system workflow may getterminated at step C, if the customer service representativesatisfactorily answers the client query. In addition, the ticketingsystem may allow a supervisor to identify competencies of a customerservice representative by monitoring past performance. The supervisormay use the ticketing system to identify competencies of customerservice representatives for specific kinds of inquiries. The ticketingsystem may also provide the supervisor a means to determine how acustomer service representative is assigned the next inquiry.

FIG. 13 illustrates a schematic block diagram of an alternate embodimentof the embodiment shown and described with respect to FIG. 11 thatincludes a website hosting platform including a CRM system or anOperational support system 114 (‘OSS 114’) with a reporting facility1302. As described herein, the OSS 114 may enable access to any elementof the website hosting platform during client/agent interactions withany component of the unaffiliated web hosting platform. In addition tothe features and capabilities associated with embodiments in FIGS. 11and 12, the embodiment of FIG. 13 may include a reporting facility 1302that may provide various reports that may be relevant to a businessfunction of the platform. Reports from the reporting facility 1302 maybe routed to the business operations facility 140, such as financialreports, and the like.

The OSS 114 may include a CRM facility, a client messaging facility, aclient ticketing system, a reporting and operational managementdashboard facility, a billing system, a scaled down console forpartners, and the like. Although these facilities may not be directlyintegrated with the client 101 interface, an administrator or agent 118may access these services to accomplish tasks related to customerservices that have been pending or require immediate attention. Thereporting facility 1302 may automatically, periodically, manually, orany combination thereof, capture agent access to these services andreport them.

Combining the OSS 114 with the reporting facility 1302 may facilitatetranscending traditional reporting technology by incorporating billing,usage, traffic, web hosting platform performance and utilization, andother items in a reporting dashboard. Such combining of features mayhelp to reduce web hosting costs, identify future business needs, betterserve a client, and the like.

A client support front end for the OSS 114 may be integrated with thereporting facility 1302 to generate customized messages and/or reportson behalf of the client. The reporting facility 1302 associated with theOSS 114 may utilize off the shelf reporting tools, customized reportingtools, or an open database connectivity (ODBC) connection to generatecustom reports or web pages without the need for one-off databases. Thereporting facility 1302 may be a part of a business management orservice management capability of the common service architecture 100.

A variety of services may be offered by the common service architecture100 web hosting platform. While many services being provided may benative to the web hosting platform, there may be others that areavailable to web hosting clients and clients' clients from thirdparties. Using third parties may allow the web hosting platform toreadily expand the type and number of services offered without taking ona large product development program. This may facilitate making someservices available through the platform sooner than if developed asnative to the platform. The third-party services 128 may be provided bya wide range of vendors and may cover important service areas such ascommerce, communication, marketing, website management, and the like.

The third-party services 128 may be associated with the web hostingplatform of the common service architecture 100 through a variety ofinterfaces, including through the load balancer 112, and the like. Theplatform may alternatively include a third-party service facility forproviding interface with, management of, and access to the third-partyservices 128. In an example the load balancer 112 may be associated witha third-party service facility that may operate on one or more of theservice pools. One feature of the third-party service facility may allowa web hosting service provider to offer a service provided by athird-party to a web hosting client or to the web hosting client'sclient. The services provided by a third-party may be accessible to theclient through a web hosting control panel. The services provided by athird-party may be integrated with or simply accessible through the webhosting platform. An integrated service provided by a third-party may beconnected to the web hosting system by an API. A third-party service maybe integrated with web hosting client's websites through a plug-incapability that may allow a web hosting client to simply identify aselected third-party service to the platform and third-party integrationsoftware operating on the platform may configure an interface throughwhich the web hosting client's clients may access the third-partyservice. Alternatively, a third-party service may operate independentlyof the web hosting platform and access to the third-party service (e.g.by a web hosting client) may be done through accessing a URL thatnavigates out of the web hosting platform domain to the third-partydomain. The web hosting platform may be configured with third-partyservices interfaces that accept a plugin (similar to a plug-in forproviding additional functionality to an email program or a web browser)provided by the third-party that seamlessly makes the third-partyservices accessible to web hosting clients and their users. It isenvisioned that a web hosting client may be able to select a third-partyservice by comparing the third-party services 128 based on a number ofcriteria including, but not limited by type of service, cost, desiredoutcome, brand of service, and the like.

Third-party service providers may desire to engage web hosting platformclients so as to establish a business relationship with the client. Thismay be beneficial for the client, the third-party and a facilitator ofthe web hosting platform. While some of the third-party services 128 maybe offered at no direct cost to the web hosting platform clients, theremay be opportunities for the web hosting platform facilitator to deriverevenue from a service provided by a third-party. The revenue may indeedbe derived from the client or it may be paid by the third-party, such asfrom revenues derived by the third-party from other clients of theservice, advertisers, and the like. In an embodiment where revenue isgenerated from the third-party, the revenue may be a flat fee, aperiodic fee, a fee based on a number of the web hosting platformclients that use the service, a percentage of the third-party revenuefrom their use, a referral fee, and the like. In a case where revenue isgenerated from a client, the revenue may be a one-time charge, aperiodic charge, a percentage of sales, and the like.

The web hosting service provider may provide an incentive for a clientto use a service provided by a third-party. Such an incentive mayinclude a free trial, a credit, a discount, a promotional term, and thelike. Alternatively, the web hosting service provider may include aservice provided by a third-party free of charge. The web hostingservice provider may offer to supplement the free service with anadditional component. The web hosting service provider may generaterevenue from a client agreeing to the additional component. The webhosting service provider may provide maintenance service for a serviceprovided by a third-party. The web hosting service provider may generaterevenue from the maintenance service by charging a one-time maintenancefee, a periodic maintenance fee, a fee based on actual maintenanceservices provided, and the like.

The web hosting service provider may rebrand a service provided by athird-party to maintain uniform look and feel for a client. A client maychoose a service from among a plurality of substantially identicalservices which may be differently branded.

The third-party service facility may allow collaboration between the webhosting service provider and a plurality of third-party serviceproviders. A web hosting service provider may compile a list of approvedthird-party service providers. The list of approved service providersmay be stored in the shared storage 106. The web hosting serviceprovider and the third-party service provider may engage in apartnership. The partnership may include an arrangement of sharingrevenue, a combined marketing strategy, a complimentary service, and thelike. The third-party partnership may be based on various factors suchas competency in a specific technology area, competitive advantage in aparticular process, strategic organizational goal, and the like.

The web hosting platform may provide opportunities for its clients tocommercialize their web hosting content and web pages. Suchcommercialization may include providing tools for performingtransactions directly with a client's users, collecting fees fromadvertisers, and the like. Such capabilities may be provided bythird-parties through a commerce service that may be accessed through athird-party service facility as described herein. A third-party commerceservice may include a means for a web hosting client to accomplish asale transaction with its clients. The sale transaction may be one of areal-time transaction, a delayed transaction, an off-line transaction,and the like. The commerce service may include a means to allow a webhosting client's clients to select an item, a quantity of an item, adelivery method, a payment method, and the like. The item may be one ofseveral type of item, including a product and a service. The quantity ofan item may vary based on type of item, availability of item, and thelike. The delivery method may also vary based on type of item, and mayinclude instant (online) delivery, shipping, personal, and the like. Theweb hosting client's clients may be able to enter a relevant address forthe sale transaction, which may include a billing address, a shippingaddress, and the like. The payment method may also vary based on type ofitem, and may include credit card, check, wire transfer, online payment,gift card, and the like.

A third-party commerce service may include a shopping cart application.The shopping cart application may be one of an open source application,a commercial application, and the like. The web hosting service providermay offer different levels of the shopping cart application. Thedifferent levels of shopping cart application may include a free starterversion and one or more upgraded versions. The web hosting provider mayderive revenue from an integration of a shopping cart with the client'swebsite, a sale of an upgraded version of the shopping cart for use withthe client's website, a software update for the shopping cart, a sale ofadditional features of the shopping cart, and the like.

The shopping cart application may be a freely-available application. Theweb hosting provider may be able to derive revenue from an integrationof the freely-available shopping cart application with its hostingenvironment.

A third-party commerce service may provide a merchant account facility.A merchant account is a type of bank account that allows a business toaccept a payment from a customer by a debit or credit card. The merchantaccount also serves as an agreement between a retailer, a merchant bankand payment processor for the settlement of a credit and/or debit cardtransaction. The merchant account facility may permit the web hostingservice provider to allow a client a means to gather purchaseinformation from a client's client. The merchant account facility mayprocess the purchase information or may refer the information to athird-party for processing. The web hosting service provider maygenerate revenue from the merchant account facility. The revenue may bebased on one of a flat fee, a percentage of a sale, and the like.Alternatively, the payment method included with the commerce service mayinclude an online payment. The online payment may include a paymentsystem such as PayPal, an escrow system, and the like. A client's usermay use an online payment to pay for a purchase made from a client'swebsite. The web hosting service provider may receive a payment based onprice of item sold, volume of sale, periodic flat fee, and the like.

A third-party service may include facilitating various type payments forelectronic transactions, such as a gift card. A client may issue a giftcard through a third-party which would allow a gift card holder to makea purchase from the client for up to the amount of the gift card. Thegift card may be one or more of electronic, paper, and the like. The webhosting service provider may receive payment when a client issues a giftcard, when a client's user uses a gift card, and the like. The webhosting service provider may receive a payment based on amount of eachgift card, number of gift cards issued, number of gift cards redeemed,periodic flat fee, and the like.

The commerce service may allow a client to sell third-party inventory onits web site. A client may sell third-party inventory to supplement theclient's own catalog.

A third-party commerce service may include providing security fortransactions conducted through web sites hosted by the web hostingplatform. The security features may allow a client's user to shop from aclient's website with a degree of confidence. The security provided mayinclude one or more of a security certificate, a security rating, anecommerce approval, and the like.

Communication, particularly electronic communication is critical togaining the greatest benefit from hosted web services, and for buildinga successful web presence. Therefore, the web hosting platform mayensure that communication features and services are readily available toweb hosting clients. While the platform may provide variouscommunication services directly, there are many third-partycommunication services that may provide capabilities that go beyondthose of the platform provided communication services. Therefore, theplatform may provide a variety of third-party communication services. Inorder to fulfill a customer's communication need, the communicationservice may include a server for email, calendar, contact list, VOIP,and the like. The communication service may provide more than one levelof communication service. Different levels of communication service maybe provided depending on cost, client need, size of client'sorganization, type of service desired, type of technology utilized, andthe like. The web hosting service provider may integrate thecommunication service into the hosting environment. The web hostingservice provider may provide access to a third-party communicationservice that is not integrated with the web hosting platform. The webhosting service provider may generate revenue from a client's use of thecommunication service by billing either the client or the third-partyservice provider. The revenue may be generated by charging a periodicfee for access, by charging on a volume of use basis, by charging aprovider a per-client fee, and the like. In an example of acommunication service a client may access an email server or clientsoftware, such as an EXCHANGE server or the like. The EXCHANGE servermay provide a client with advanced features, such as managing email,calendar, contact list, and the like. Such a communication service mayprovide access to collaboration features of email client programs, suchas OUTLOOK and OUTLOOK WEB ACCESS to facilitate a client securelysharing information.

A third-party communication service associated with the web hostingplatform may include mobile access. Mobile access may allow a client toaccess the aspects of the web hosting platform, such as operationalsupport services from a wireless device. A wireless device may include acellular telephone, a smartphone, a personal data assistant (PDA), andthe like. Mobile access may include BLACKBERRY service, ACTIVESYNCservice, GOODLINK service, and the like.

The web hosting platform may be associated with a third-party servicecapability that may include a domain service. The domain service mayprovide a client the ability to manage a domain, register a domain, maskdomain registration information, park a domain, and the like. Thesupport and/or billing for the domain service may be provided by the webhosting service provider, by a third-party, and the like.

In a case, when a client uses the domain service to park a domain, anadvertisement may be displayed in an end client's web browser when theparked domain is accessed. The advertisement displayed may be related tothe parked domain, a search word used to find the parked domain, ageneral demographic, and the like. The client owner of the parked domainmay influence which advertisements are presented. In exchange forfacilitating parking the domain, the web hosting service provider mayreceive a percentage of the revenue when a client clicks on theadvertisement that is presented.

The web hosting platform may be associated with a third-party servicethat may include a marketing service. Such a marketing service mayinclude a web directory listing, an advertising platform, an emailmarketing system, a website rating system, a customizable toolbar, andthe like. The web directory listing service may provide a means toimprove a client website's rank among results in a search engine. Animprovement in the rank may be produced through purchase of a higherrank, optimization of a client's website that results in a higher rank,and the like. The web directory listing may be customized by websitetype, client's user demographics, intended market, and the like. Theadvertising platform may include a pay-per-click marketing campaign,YAHOO search, GOOGLE ADWORDS, and the like. The email marketing systemmay allow a client to create and send a newsletter, offer, announcement,promotion, and the like to his/her client. A client may use the emailmarketing system to communicate with his/her client to generate,maintain, enhance, and the like a relationship with the client. Arelationship with a web hosting client's client may include afriendship, a professional relationship, and the like. The web hostingclient may use the email marketing system to build and manage an e-maillist. A web hosting client may use the email marketing system toinitiate, monitor, continue, suspend, and the like an e-mail campaign.The marketing service may allow a web hosting client to import a targetaudience list from a database.

The marketing service may include a design service. The design servicemay include logo design, website design, promotional material design,newsletter design, and the like.

The third-party services 128 provided by the web hosting platform mayinclude a website management service. Such a website management servicemay include website design, creation, maintenance, backup, recovery, andthe like. Website design may include a range of design services,including complete design, predefined template, drag-and-drop designfacility, and the like. The website maintenance facility may include anoptimization service which may recommend localization of certainservices for optimized load times thereof. The website maintenancefacility may scan the website to prevent an attack by malware, and thelike.

The third-party services 128 provided by the web hosting platform may beproduced with a wide variety of programming tools and may be implementedin a variety of programming languages, including various combinations toprovide the various services (e.g. HTML, FLASH, and the like for webbrowser display integration). The third-party services 128 may be basedon open-source software, off the shelf modules, fully customizedsoftware, a combination thereof, and the like.

FIG. 14 illustrates a schematic block diagram of a common servicearchitecture 100 capable of offering a third party service 128 to aplurality of websites. The common service architecture 100 may offer aplurality of services such as an HTML service, an email service, a chatservice, and the like, to the websites. Exemplary websites may include astudent owned website 310, a small business website 312, and a corporateintranet website 314. One or more of the plurality of services may beadapted to contribute to a distinct service package for the websites,which may be unrelated or unaffiliated. Further, one or more servicesmay serve a third party interface 1402 that may be capable of allowing athird party to access the distinct service package subscribed by thewebsite using the third party service 128. Alternatively, the thirdparty interface 1402 that may facilitate allowing web hosting client oruser of a hosted website to access the third party service as acomponent of a distinct service package that is offered to the website.A third party, a web hosting client, or a user of a hosted website mayexperience information consistent with a market specific serviceoffering associated with the distinct service package, the hostedwebsite, or any combination thereof.

Third party services 128 may be marketed in association with the commonservice architecture 100 in a plurality of market specific serviceofferings, such as through a market specific service offering website.Access to a third party service via the common service architecture 100may facilitate providing information associated with the third-partyservice so that it appears to be consistent with a market-specificservice offering, such as a market specific marketing website. A clientof the common service architecture 100 may access the services of thearchitecture through a market specific interface that may be enabled bythe skins 120 and the code library 122. The client and/or a user of ahosted website may access the third party services through the samemarket specific interface.

Many services provided to the websites may be native to the commonservice architecture 100 and there may be other services such as thirdparty services that may be made available to web hosting clients andusers of the hosted websites. Employing services offered by thirdparties may allow the common service architecture 100 to readily expandthe type and number of services offered by the web hosting platformwithout taking on a large product development program for developingthese services. This may facilitate making some services availablethrough the common service architecture 100 sooner than if developed asnative to the common service architecture 100. As mentioned, the webhosting platform may offer specific services for use by the thirdparties in a distinct service package. The service package may addressesspecific needs, preferences, contractual requirements, subscriptionpolicies, and the like of a hosted website. The third-party services maybe provided by a wide range of vendors and may include exemplaryservices such as commerce, communication, marketing, website management,and the like.

The third-party services such as the third party service 128 may beassociated with the common service architecture 100 through a variety ofinterfaces, such as a third party interface 1402. The common servicearchitecture 100 may alternatively include a third party servicefacility for providing the third party interface 1402 with managementof, and access to the third-party service 128. One feature of the thirdparty service facility may allow a web hosting service provider to offera service provided by a third-party to a web hosting client or users ofthe web hosting client. The services provided by a third-party may beaccessible to the client through the client's web hosting control panel.The services provided by the third-party may be integrated with orsimply accessible through the common service architecture 100.

An integrated service provided by the third-party may be connected tothe common service architecture 100 by an application programminginterface (API). Further, the third party service 128 may be integratedwith hosted websites using the third party service 128 through a plug-incapability. The plug-in capability may allow a web hosting client tolink a selected third party service to a distinct service packageoffered by the web hosting platform. Third party integration softwareoperating on the common service architecture 100 may configure aninterface through which the web hosting clients and/or users of a hostedwebsite may access the third party service 128.

Alternatively, the third party service 128 may operate independently ofthe common service architecture 100 and access to the third partyservice 128 (e.g. by a user of a website or by a client hosting thewebsite) may be done by accessing a URL that navigates out of the commonservice architecture 100 domain to the third party domain. The commonservice architecture 100 may be configured with a third-party serviceinterface 1402 that may accept a plug-in (e.g. similar to a plug-in forproviding additional functionality to an email program or a web browser)provided by the third-party. The plug-in may seamlessly make the thirdparty service 128 accessible to clients hosting their websites and thehosted website users.

A client hosting a website may be able to select a third party serviceby comparing the third party services offered by the common servicearchitecture 100 based on a number of criteria including, but notlimited by type of service, cost, desired outcome, brand of service, andthe like.

Third party service providers may desire to engage the web hostingplatform clients so as to establish a business relationship with theclient. This may be beneficial for the client, the third-party, and afacilitator of the common service architecture 100. In an example, theremay be opportunities for the web hosting platform facilitator to deriverevenue from a service provided by a third party. The revenue may bederived from the client or it may be paid by the third party, such asfrom revenues derived by the third party from other users of theservice, advertisers, and the like.

When revenue is generated from the third party, the revenue may be aflat fee, a periodic fee, a fee based on the number of the clients thatuse the third party service 128 in their website, a percentage of thethird-party revenue from their use, a referral fee, and the like. Whenthe revenue is generated from a client, the revenue may be a one-timecharge, a periodic charge, a percentage of sales, and the like.

The web hosting service provider may provide an incentive for a clientto use a service provided by a third-party. Such an incentive mayinclude a free trial, a credit, a discount, a promotional term, and thelike. The web hosting service provider may include a service provided bya third party on a website, free of charge. Further, the web hostingservice provider may offer to supplement the free service with anadditional component. The web hosting service provider may generaterevenue from a client agreeing to the additional component. The webhosting service provider may provide maintenance service for a serviceprovided by a third-party. The web hosting service provider may generaterevenue from the maintenance service by charging a one-time maintenancefee, a periodic maintenance fee, a fee based on actual maintenanceservices provided, and the like.

The web hosting service provider may also rebrand a service provided bya third-party to maintain uniform a look and feel of the third partyservice 128 for a client. A client hosting a website may choose aservice from among a plurality of substantially identical services,which may be differently branded.

The third party service facility may allow collaboration between the webhosting service provider and a plurality of third-party serviceproviders. A web hosting service provider may compile a list of approvedthird-party service providers. The list of approved service providersmay be stored in a shared database, such as common data store 106 of thecommon service architecture 100. The web hosting service provider andone or more approved third-party service providers may engage in apartnership. The partnership may include an arrangement of sharingrevenue, a combined marketing strategy, a complimentary service, and thelike. The third-party partnership may be based on various factors suchas competency in a specific technology area, competitive advantage in aparticular process, strategic organizational goal, and the like.

Exemplary third party services may include service for performingelectronic transactions, marketing, and the like. Specifically, athird-party service may include a commerce service that may include ameans for a client to accomplish a sale transaction with a user of awebsite. The sale transaction may be one of a real-time transaction, adelayed transaction, an off-line transaction, and the like. Thethird-party commerce service may include a shopping cart application.The shopping cart application may be one of an open source application,a commercial application, and the like. Another exemplary third partyservice 128 may be a marketing service. The common service architecture100 may be associated with the marketing service. Such a marketingservice may include a web directory listing, an advertising platform, anemail marketing system, a website rating system, a customizable toolbar,and the like.

Traditional web-hosting platforms have well-documented drawbacks. One ofthese drawbacks is the cost and complexity of switching from oneplatform to another. In addition to the cost associated with terminatinga web-hosting service agreement, a client seeking to change his or herweb-hosting service provider would have to move data from one server toanother, and may encounter downtime during the migration process, makingthe client's web site unavailable. These downtimes present a seriousbarrier to a client switching between different web-hosting serviceproviders. A migration facility capable of minimizing or preferablyeliminating the downtime associated with a client's switch ofweb-hosting service provider may be an effective solution to thisbarrier and may open greater opportunities for web-hosting clients tofind a web-hosting provider that offers the balance of branding, cost,features, and scalability desired.

Migration drawbacks may also be significant barriers to effectivebusiness activities related to merging (e.g. through acquisition)web-hosting providers. Consolidation is a common process for maturingand reducing costs in various industries so reducing the barriers tosuch consolidation may prove very beneficial for the participants in theweb-hosting industry at large. Generally, when a web-hosting serviceprovider acquires another web-hosting service provider, to achieve manyof the benefits of consolidation, the acquired provider's clients needto be merged with the acquirer's web-hosting system and serviceofferings. One approach to this is to migrate each of the web-hostingclients of the acquired provider into the acquirer's system. In order toprevent client dissatisfaction which can result in loss of revenue, thismigration must be as seamless as possible, with no downtime for clientsof the acquired web-hosting provider and no disruption of service forthe acquiring web-hosting provider's clients. Although consolidationprovides great benefits, migration often must maintain the look and feel(e.g. user interfaces, languages, features, etc.) of the acquiredweb-hosting provider. With at least these factors being considered, aweb-hosting client migration facility for migrating a client from anacquired web-hosting system to the acquiring web-hosting architecturewhile eliminating web site downtime or data access disruption canfacilitate a web-hosting service provider growing his/her business byacquiring other web-hosting service providers.

Such a web-hosting migration facility may be offered by the commonservice architecture 100 to facilitate client relocation to the commonservice architecture 100. A web-hosting migration facility 130 of thecommon service architecture 100 may also facilitate migrating fromvarious configurations of web-hosting providers to the common servicearchitecture 100. Because the common service architecture 100 may usededicated service pools (of servers) and traditional web-hosting serviceproviders, or a combination of all (or substantially all) services onone server or group of servers as may be needed to support the webhosting client's level of service requirements, the migration facility130 must support migration among these substantially different webhosting architectures. In the event that a service that is beingprovided to an acquired web hosting client is not provided by one of theservice pools of the common service architecture 100, the migrationfacility 130 must be flexible enough to allow for creation of newservice offerings in the common service architecture 100. This may bedone by establishing new service pools or adding a new service to aservice pool that already offers a similar service (e.g. establishing adifferent type of email service to execute on servers in existing emailservice pool).

To facilitate reduced or ideally zero down time for a web hosting clientbeing migrated to the common service architecture 100, migration maytake advantage of migration features of the common service architecture100 that may allow, among other things partial data transfer and backup,as well as partial website (e.g. URL, individual service, etc.)migration without interruption of service or data access. Partial datatransfer and backup may allow a portion of a web hosting client'scontent to be relocated into the shared storage 106 of the commonservice architecture 100 so that client access to content providedthrough the web hosting client's web site (for example) can be directedto either the original data source or through the common servicearchitecture 100 to the shared storage 106. Similarly, partial websiteor service-specific migration may enable migration of services overtime. In an example, email accounts using an email service beingprovided by a web hosting provider that has been acquired that is thesame as an email service offered by the common service architecture 100,may be migrated before other portions of an acquired web hostingclient's account. In this way, the migration may be accomplished inone-step or in a multi-step process where services are moved separately.The service pool may provide a backup of the migrated services.

The migration facility 130 may transfer a plurality of web services,such as web page code, email service, conference service, calendarservice, e-commerce service, exchange service, databases, and the like.The migration facility 130 may operate in a fully automated manner.

Migration may require or may benefit from separating services to bemigrated from data to be migrated. As is described herein, the commonservice architecture 100 treats services and data differently thanconventional web hosting architectures to take advantage of its servicepools and shared data store features. Therefore, the migration facility130 may separate the services to be migrated from and the underlyingdata to be migrated. However, separating services from data may be acomplex operation and may require some level of manual interaction.Migration may therefore combine elements of automated and manualtransfer.

The migration facility 130 may include an API that may facilitateautomating the migration process. The API may allow programmaticallyinterfacing with the plurality of service pools, shared databasefacility, load balancer 112, the skins 120 and the code library 122, andany other feature, service, or interface of the common servicearchitecture 100, and the like. The API may reside in the code library122 and it may be dynamically initialized in real time for migrating aclient's services into the common service architecture 100. The API mayprovide access to automated tools for migration (e.g. software) that maynormally execute in the load balancer 112 for migration of a client fromanother web-hosting platform. The API may be distributed so thatportions of it may exist in various facilities of the common servicearchitecture 100, such as the code library 122, the load balancer 112,the service pools, the OSS 114, and the like, and may be executeddynamically and in real time.

The migration approach may depend upon a number of factors, such as, butnot limited to: service and data separation complexity, type of data,format of data, amount of data, type of metadata associated with data,structural and logical association of data, and the like. Migrationapproach may also depend on the general category of the data,applications, and/or services provided in the web hosting account to betransferred. The migration facility 130 may facilitate tailoring themigration process depending on this migration category. In an example,the migration facility 130 may provide a user interface that may allowthe client to select the migration category. Migration categories mayinclude one or more of data migration, application migration, businessprocess migration, and the like. As a further example of migrationcategorization, application migration may be required when CRM (CustomerRelationship Management) or SCM (Supply Chain Management) software orthe like are embedded in a client website being migrated. Because a webhosting account to be migrated may include more than one migrationcategory, the migration facility 130 may be tasked with performing amigration involving several migration categories. Through theaforementioned user interface, a client may be able to select thecategories to migrate, as well as the order in which to complete themigration.

Data in a source web-hosting account may be formatted differently thanthe data in the shared storage 106. Consequently, some reformatting orformat conversion may be required for proper migration. In anembodiment, the migration facility 130 may automatically transformclient data from one format to another, such as from a database formatto an XML format, or vice-versa.

Application migration may involve automated, semi-automated, and/ormanual migration. Automated migration of an application may beapplicable for some common applications or applications for which thecommon service architecture 100 is already authorized to execute (e.g.through a license for the application). Manual migration of anapplication may be appropriate for custom applications or forapplications for which a new license must be acquired and may beaccomplished by physically installing the application in the commonservice architecture 100.

The migration facility 130 may facilitate migration of a businessprocess by identifying individual components, or steps, of the businessprocess and mapping the components using business-process managementtools on the common service architecture 100 before migration of clientdata. Client data integrity is thus maintained throughout the migrationprocess. This migration continues until the entire business process andbusiness logic embedded in the process is migrated.

The migration facility 130 may provide a plurality of migration methods.A user presented with a selection of migration methods may pick a methodmost suitable for a particular client, situation, data type, and thelike. A migration method may differ from another migration method on howclient data is separated from client services.

The migration facility 130 may process and analyze data as part of themigration process. The data may be broken into a plurality of componentsthat meet one or more criteria of data categories associated with thecommon service architecture 100. Each component may be migrated into thecommon service architecture 100 and stored in the shared storage 106.These steps may be performed using automated software tools withoutmanual intervention.

The migration facility 130 may maintain the security and accesspermission associated with the data being migrated when it is migratedinto the shared storage 106 so that data security details such as accesspermissions, passwords, and the like, that were required to access thedata in the acquired web hosting platform may be enforced using the datasegmenting and security capabilities of the shared storage 106 of thecommon service architecture 100. Such security configurations may affectrouting of the migrating data through the load balancer 112 so that thedata security is maintained throughout the migration process.

The migration facility 130 may include a third party migration tool orservice. The third party migration tool or service may facilitate themigration of third party services into the common service architecture100. For example, email address book entries may be transferred into thecommon service architecture 100 using the proprietary tools of the emailsoftware provider. Likewise, the migration facility 130 may utilizeTDMF™ (Transparent Data Migration facility 130) from SOFTEK to providecapabilities such as throttling/pacing data movement during migration.

The migration facility 130 may ensure secure transfer of data into thecommon service architecture 100. The migration facility 130 may use amarker or a save point during the migration process to facilitate ensuredata integrity during migration. The migration facility 130 may be ableto roll back a migration to a particular marker (also known as a savepoint) in case of failure during the migration process. The migrationfacility 130 may also insert a marker or save point between each datapoint. In the event of data migration process failure, subsequenttransfer of data may initiate from last marked point. In case of asevere migration failure, the migration facility 130 may roll back allthe previously taken migration steps.

The migration facility 130 may achieve hardware independence byincorporating software capable of integrating multiple data repositoriesand hardware such as hard disks, free agents, and the like seamlesslyinto the common service architecture 100 during the migration process.This may be important since the common service architecture 100 mayinclude services pools catering to different services. The service poolmay be configured using a plurality of servers, each of which may havedifferent configurations, hardware, processing capability, manufacturer,and the like.

A client may wish to migrate to the new web-hosting platformindependently, without involving the client's existing web hostingservice provider. This may be the case when secrecy of data is paramountor when the client wants to utilize his or her own resources fortransferring data. The migration facility 130 may provide a migrationhelp utility to aid a client in such a transfer. The help utility mayinclude a list of steps that the client may need to follow to undertakethe migration into the common service architecture 100. The migrationhelp utility may include a demonstration to show a client how to carryout the migration process. For example, the first migration help utilityscreen may list the steps involved in the migration. The second step mayinvolve identifying the type of migration, the hardware and softwareinvolved in the migration, and the various errors that may occur duringthe migration process. The migration help utility may also provide alist of critical issues observed during the migration processspecifically in migrating business processes.

The migration facility 130 may collect information about existing webhosting configuration. By collecting existing web hosting configurationinformation the migration facility 130 may be able to create a new webhosting platform that more accurately matches a client's needs. Theconfiguration information collected may be related to severconfiguration, network configuration, database configuration, and thelike. For example, the server configuration may include collection ofinformation related to number of CPUs, logical partitions, type of filesystem, and the like. This information may be collected using automatedtools. Alternatively, a user interface may be provided for receivinginformation about the web hosting configuration to be migrated. Thecorresponding configuration information may be entered by the client orby the web hosting service provider and then used by the migrationfacility 130 to configure the migration methodology.

The migration facility 130 may include a software tool with an abilityto facilitate creating a migration data map based on the data andservices to be migrated. The tool may include a graphical user interfacethat a client or web hosting provider may use to create a migration dataand service map that may help guide and ensure compliance with theoriginal intent and capabilities of the web hosting account beingmigrated.

The migration facility 130 may initiate the data migration process byidentifying data structures representing data and other web services tobe migrated. This identification step may include loading datastructures and generating a map of associated data. The migrationfacility 130 may use a software tool to facilitate automaticallyidentifying data from the data map to be transferred to the commonservice architecture 100. The map of associated data may be modifiedmanually to assure accuracy. Rules for transfer of data may be createdbefore initiating the transfer of data. The data migration repositorymay be used as a temporary storage for analysis, recording errors,correcting exceptions, creating a log of rejects between the oldarchitecture and the common service architecture 100, and the like. Thetemporary storage may be a part of the common service architecture 100or may be external; that is, outside both the old architecture and thecommon service architecture 100. Finally, the migrated data may betransferred into the common service architecture 100.

The migration facility 130 may allow direct migration, phased migration,or parallel migration of data. Direct migration may involve moving theexisting data from the old architecture to the common servicearchitecture 100 completely and running the same from the common servicearchitecture 100. Likewise, the phased migration may be by moving thedata to the common service architecture 100 in segments. During phasemigration, both the source and common service architecture 100 mayoperate in parallel.

Further, migration may also involve transfer of Domain Name Server(DNS). In this aspect, the migration facility 130 may include a softwaremodule that may automatically create a log of configuration informationfrom the old architecture and implements it on the common servicearchitecture 100. Alternatively, the DNS configuration setting may beapplied manually by entering the required information into the commonservice architecture 100. The DNS may be replicated in the commonservice architecture 100 and both the new and the old architecture maybe operated conditionally for a specific time before the oldarchitecture is removed.

Likewise, in some instances migration may include replication and/ormigration of active directory services, especially in an environmentwhere the Internet and intranet reside on a single server. In suchcases, the migration of active directory may be facilitated by eitherreplicating the active directory in the common service architecture 100using an automated tool or manually copying the configuration settingsinto the common service architecture 100. In another aspect, anautomated software tool may transfer the active directory residing inthe old architecture directly to the common service architecture 100.

The migration facility 130 may ensure the transfer of a security relatedparameter, such as a domain password, registry key, access informationof the existing host, transfer of databases, SSL certificates, versioncompatibility, email addresses and the like. Failure to transfer any oneof these parameters may result in failure of the migration process. Inthis case, manual intervention may be required to complete the migrationprocess.

Once the migration of a website is complete, the migration facility 130may utilize an automated testing facility to ensure full functionalityand configuration of the migrated website. In addition, errors detectedduring testing may be recorded in a log file and utilized forrectification of correction of those errors.

Web hosting architectures may include physically dedicated or sharedhosting and virtual server-based hosting. In physical dedicated hosting,each web hosting client may be provided a dedicated physical computingresource (e.g. a blade in a rack-based server deployment). Physicalhosting may also be executed as a shared service in which a singleserver handles multiple web hosting clients. This type of web hostingservice may be suitable for low cost, low performance hosting. Virtualserver web hosting may enable a web hosting provider to offernear-dedicated server capabilities and performance without the costs ofindividually dedicated hardware. A virtualized web hosting platform mayhide physical characteristics of the platform from the web hostingclient but may still associate one web hosting client to one virtualserver (also known as a container).

Due to the general structural constraints of internet style routing,migration techniques have been based on a batch process that requirestaking down a batch of URLs (e.g. 255) to migrate even one URL. Therouting limitation relates to a constraint that a URL may not beadvertised as existing at two different physical places at the sametime; therefore, changing the physical location of even one URL mayresult in various URLs within the same range of 255 URLs being affected.Therefore, batch-based migration techniques may affect up to as many as255 URLs at a time.

The migration facility 130 may embody a virtual network-based migrationtechnique that may overcome the routing limitations of batch-basedmigration while supporting individual IP address migration. Thistechnique may include setting up a proxy (e.g. virtual LAN) for all IPaddresses to be migrated and managing routing based on the migrationstatus. With this technique, migration may occur on a URL-by-URL basiswithout other URLs being affected. In addition, new physical IPaddresses may be broadcasted one-by-one as migration proceeds.

Migration may involve various source and destination architectures.Although migration may generally support the features and benefitsdescribed hereinabove, particular configurations of source anddestination architectures may necessitate modifications to migration.The following scenarios exemplify some of the variety of migrationarchitectures covered by the migration facility 130.

The migrating facility of the common service architecture 100 mayfacilitate migration of a web hosting service from one architecture toanother, where at least one may be service pool architecture. Themigrating facility may include an automated tool for migrating a websitehosting service from a first website hosting architecture to a secondwebsite hosting architecture, the first architecture may include aserver architecture that may serve a plurality of services dedicatedexclusively to a specific website. The second web hosting architecturemay include a server architecture that may serve a plurality of commonservices to a plurality of unrelated and/or unaffiliated websites.

The migrating facility 130 of the common service architecture 100 mayfacilitate migration of a web hosting service from a one box percustomer architecture to a multiple box per customer architecture. Themigrating facility 130 may include an automated tool for migration of awebsite hosting service from a first website hosting architecture to asecond website hosting architecture. The first architecture may includea server architecture that may serve the services necessary for aspecific website from a single machine and the second web hostingarchitecture may include a server architecture that may serve aplurality of common services from a plurality of machines to a pluralityof unrelated and/or unaffiliated websites.

The migrating facility 130 of the common service architecture 100 mayfacilitate migration of a web hosting service from a one box percustomer architecture to a cloud computing architecture. The migrationfacility 130 may include an automated tool for migration of a websitehosting service from a first website hosting architecture to a secondwebsite hosting architecture. The first architecture may include aserver architecture that may serve the services necessary for a specificwebsite from a dedicated machine and the second web hosting architecturemay include a server architecture that may serve a plurality of commonservices from a plurality of machines to a plurality of unrelated and/orunaffiliated websites using a cloud computing architecture. Thededicated machine of the first website hosting architecture may have oneor more substantially duplicate machines for backup purposes.

The migrating facility 130 of the common service architecture 100 mayfacilitate migration of a web hosting service from a one box percustomer architecture to a grid computing architecture. The migrationfacility 130 may include an automated tool for migration of a websitehosting service from a first website hosting architecture to a secondwebsite hosting architecture. The first architecture may include aserver architecture that may serve the services necessary for a specificwebsite from a dedicated machine and the second web hosting architecturemay include a server architecture that may serve a plurality of commonservices from a plurality of machines to a plurality of unrelated and/orunaffiliated websites using a grid computing architecture. The dedicatedmachine of the first website hosting architecture may have one or moresubstantially duplicate machines for backup purposes.

The migrating facility 130 of the common service architecture 100 mayfacilitate migration of a web hosting service from a one box permultiple customer architecture to a cloud or grid computing architecturewith many boxes for many customers. The migration facility 130 mayinclude an automated tool for migration of a website hosting servicefrom a first website hosting architecture to a second website hostingarchitecture. The first architecture may include a server architecturethat may serve the services necessary for a plurality of distinctwebsites from a dedicated machine and the second web-hostingarchitecture may include a server architecture that may serve aplurality of common services from a plurality of machines to a pluralityof unrelated and/or unaffiliated websites using at least one of a cloudcomputing architecture and a grid computing architecture. The dedicatedmachine of the first website hosting architecture may have one or moresubstantially duplicate machines for backup purposes.

The migrating facility 130 of the common service architecture 100 mayfacilitate migration of a web hosting service from a dedicatedenvironment for each customer to a shared environment for multiplecustomers. The migration facility 130 may include an automated tool formigration of a website hosting service from a first website hostingarchitecture to a second website hosting architecture. The firstarchitecture may include a server architecture that may serve theservices necessary for a client's websites from a dedicated machine andthe second web-hosting architecture may include a server architecturethat may serve a plurality of unrelated and/or unaffiliated customersfrom a plurality of shared servers. The dedicated environment mayinclude dedicated memory for each customer wherein the sharedenvironment may include shared memory across multiple customers. Theshared environment may be a cloud-computing environment. The sharedenvironment may be a grid-computing environment. The shared environmentmay include a plurality of common service pools disposed across aplurality of servers.

The migrating facility 130 of the common service architecture 100 mayfacilitate migration of a web hosting service from a dedicatedenvironment for each customer to a shared environment for multiplecustomers. The migration facility 130 may include an automated tool formigration of a website hosting service from a first website hostingarchitecture to a second website hosting architecture. Each serverarchitecture may include a server architecture that may serve aplurality of common services from a plurality of machines to a pluralityof unrelated and/or unaffiliated websites. At least one environment maybe a cloud-computing environment or a grid-computing environment. Atleast one environment may include a plurality of common service poolsdisposed across a plurality of servers.

The migrating facility 130 of the common service architecture 100 mayfacilitate migration of a web-hosting service from a virtualizedenvironment to a shared environment for multiple customers. Themigration facility 130 may include an automated tool for migration of awebsite hosting service from a first website hosting architecture to asecond website hosting architecture. The first architecture may includea virtualized server architecture that may serve the services necessaryfor a client's websites from a specific virtual machine and the secondweb hosting architecture may include a server architecture that mayserve a plurality of unrelated and/or unaffiliated customers from aplurality of shared servers. The shared environment may be acloud-computing environment or a grid-computing environment. The sharedenvironment may include a plurality of common service pools disposedacross a plurality of servers.

The migrating facility 130 of the common service architecture 100 mayfacilitate migration of a web-hosting service from one architecture toanother, wherein a virtual network may be used during migration. Themigration facility 130 may include an automated tool for migration of awebsite hosting service from a first website hosting architecture to asecond website hosting architecture. A virtual network may be usedduring migration to facilitate keeping the network active during themovement of IP addresses from one architecture to the otherarchitecture.

The automated migration facility 130 as described herein may supportmigration from a wide variety of web hosting architectures to a widevariety of web hosting architectures. Some exemplary migration scenariosare described in detail herein. Others can be understood to beaccomplished using the automated migration techniques, methods,networks, and features described in the exemplary scenarios and throughthis disclosure. Migration may be automated by the automated migrationfacility 130 between the following architectures. Automated migrationmay occur from either of the two architectures to the other of the twoarchitectures noted here: cloud computing environment and cloudcomputing environment, cloud computing environment and grid computingenvironment; grid computing environment and grid computing environment;virtual server computing environment and cloud computing environment;virtual server computing environment and grid computing environment;virtual server computing environment and virtual server computingenvironment; one box per website and one box per website; one box perwebsite and cloud computing environment; one box per website and gridcomputing environment; one box per website and virtual server computingenvironment; one box per client and one box per client; one box perclient and one box per website; one box per client and cloud computingenvironment; one pox per client and grid computing environment; one boxper client and virtual server computing environment; dedicated servicesper website and dedicated services per website; dedicated services perwebsite and cloud computing environment; dedicated services per websiteand grid computing environment; dedicated services per website andvirtual server computing environment; dedicated services per website andone box per website; dedicated services per website and one box perclient; dedicated services per website and common service platform; onebox per client and common service platform; one box per website andcommon service platform; cloud computing environment and common serviceplatform; grid computing environment and common service platform;virtual server computing environment and common service platform. Any ofthe combinations described herein, and others that may be now or in thefuture known to one skilled in the art may be implemented via a virtualprivate network as described herein. Migration among the combinationsdescribed herein may be performed for a single user, single website,single client, single service, subset of clients, subset of services,subset of websites, and the like. Migration among the combinationsdescribed herein may be partial, aborted, limited, complete, initiatedfrom a first combination and completed to a second combination, migratedbetween similar architectures to provide better services lower cost, andthe like. Migration may be initiated by the receiving architecture,initiated by the sending architecture, initiated by a third party, andthe like. Migration may include use of a third party, introduction ofthird party data to satisfy a requirement of migration, migration of aportion of clients or websites or services from a first architecture toa second architecture and migration of another portion of clients orwebsites or services from the first architecture to a thirdarchitecture. Migration may include the deletion of data, deletion ofclients, deletion of websites, and the like. Other migration aspectsassociated with the automated migration facility 130 described hereinmay also be associated with the migration architecture combinationsdescribed herein.

FIG. 15 illustrates a schematic block diagram of a process for migratinga website hosting service from a first website hosting architecture(referred as ‘server architecture 1502’) to a second website hostingarchitecture (referred as ‘common service architecture 100’). The commonservice architecture 100 may include a migration facility 130 that mayinclude an automated migration tool 1530 capable of enablingsubstantially an automated migration of the website hosting service fromthe server architecture 1502 to the common service architecture 100. Inparticular, migration may include migrating support for websites in theserver architecture 1502 to the common service architecture 100

The server architecture 1502 may serve a plurality of services dedicatedexclusively to a specific website. Exemplary services served by theserver architecture 1502 may include an email service 1512, which may bededicated exclusively to a website 1504. Similarly, an email service1518 may be dedicated exclusively to website 1508. Further, an HTTPservice 1524 may be dedicated exclusively to website 1510. The commonservice architecture 100 may serve a plurality of common services for aplurality of unrelated/unaffiliated websites as described herein.

The common server architecture 100 may include a plurality of services.Exemplary services offered by the common server architecture 100 mayinclude an HTML service 302, an email service 304 and a chat service308. The plurality of services of the common service architecture 100may adapt one or more services for a specific website based on terms ofthe subscription agreed to by a web hosting client. The one or moreadapted services may be packaged into a service package. Exemplaryservice packages may include service package 320 that offers an HTML anda two email address service package, service package 322 that offers anHTML, a twenty email address and a 10 member chat service package, andservice package 324 that offers a five hundred email address and a fivemember chat service package.

Migration of the website hosting service from the server architecture1502 to the common service architecture 100 may be facilitated by theautomated migration tool 1530. The automated migration tool 1530 mayfacilitate providing services in the common service architecture 100 toa plurality of web sites that are being migrated from the serverarchitecture 1502 to the common service architecture 100. Services thatwere dedicated to a specific website in the server architecture 1502 maynow be provided using the services, service pools, service packages, andthe like that may include: web page code access, email service,conference service, calendar service, e-commerce service, exchangeservice, databases, and the like as may be provided by the commonservice architecture. The automated migration tool 1530 may operate in afully automated manner.

Migration may require or may benefit from separating services to bemigrated from website data to be migrated. As is described herein, thecommon service architecture 100 may handle services and data differentlyas compared to the server architecture 1502 in order to take advantageof features such as service pools and shared data store offered by thecommon service architecture 100. Therefore, the automated migration tool1530 may separate the services to be migrated from the underlying data(e.g. website content) to be migrated. However, separating the servicesfrom the data may be a complex operation and may require some level ofmanual interaction. Migration may therefore combine elements ofautomated and manual migration.

The automated migration tool 1530 may include an application programminginterface (API) that may facilitate automating the migration 130. TheAPI may allow programmatically interfacing with the service pools, theshared storage 106, the load balancer 112, the skins 120 and the codelibrary 122, and any other feature, service, or interface of the commonservice architecture 100. The API may reside in the code library 122 andit may be dynamically initialized in real time for migrating a client'sservices into the common service architecture 100. The API may provideaccess to the automated migration stool 1530 (e.g. software). In anexample the API may execute in the load balancer 112, a server 103, andthe like. The API may be access distributed portions of the automatedmigration tool 1530 that may, for example be distributed across variousfacilities of the common service architecture 100, such as the codelibrary 120, the load balancer 112, the service pools 102, 104 and 108,the operating support system 114 (‘OSS 114’), and the like. The APIand/or automated migration tool may be executed dynamically and in realtime.

Migration 130 may depend upon a number of factors, such as, but notlimited to: service and data separation complexity, type of data, formatof data, amount of data, type of metadata associated with the data,structural and logical association of the data, and the like. Migration130 may also depend on the general category of the data, applications,and/or the services provided in the web hosting client's account that isto be transferred. The automated migration tool 1530 may facilitatetailoring migration 130 depending on this migration category. In anexample, the automated migration tool 1530 may provide a user interfacethat may allow a user to select the migration category. Migrationcategories may include one or more of data migration, applicationmigration, business process migration, and the like. As a furtherexample of migration categorization, application migration may berequired when CRM (Client Relationship Management) or SCM (Supply ChainManagement) software, or the like, are embedded in a client websitebeing migrated. Because a web hosting account to be migrated may includemore than one migration category, the automated migration tool 1530 maybe tasked with performing a migration involving several migrationcategories. Through the aforementioned user interface, a user may beable to select the categories to migrate, as well as, the order in whichto complete migration 130.

Data in the web hosting account at the server architecture 1502 may beformatted differently than data in the shared storage 106 of the commonservice architecture 100. Consequently, some reformatting or formatconversion may be required for proper migration. The automated migrationtool 1530 may automatically transform the data from one format toanother, such as from a database format to an XML format, or vice-versa.

Applications provided by the web hosting client and/or made available tousers of the websites hosted by the server architecture 1502 may bemigrated via the automated migration tool 1530. Migrating an applicationmay involve establishing a copy of a licensed application and enablingit to execute on servers of the common service architecture 100. Anexemplary application migration may involve automated, semi-automated,and/or manual migration. Automated migration of an application may beapplicable for some common applications or applications for which thecommon service architecture 100 may be authorized to execute (e.g.through a license for the application). Manual or automated migrationtool 1530 assisted migration of an application may be appropriate forcustom applications or for applications for which a new license must beacquired. Manual migration may be accomplished for such applications byexecuting an application installation process for the desiredapplications that results in installing the application to reside inand/or execute in the common service architecture 100.

The automated migration tool 1530 may facilitate migration of a businessprocess by identifying individual components, or steps, of the businessprocess and mapping the components using business-process managementtools on the common service architecture 100 before migration of thedata. Client data integrity may thus be maintained throughout migration130. Migration 130 may continue until the entire business process andbusiness logic embedded in the business process is migrated.

The automated migration tool 1530 may provide a plurality of migrationprocesses. The migration tool 1530 may automatically select a migrationprocess for each type of data, user, website, client, and the like. Theautomated migration tool 1530 in association with the common servicearchitecture elements that facilitate client interaction may present aselection of migration processes to a user. The selection of migrationprocesses may be based on data to be migrated, the type of serverarchitecture being migrated from, and the like. The client may pick aprocess most suitable for a particular client, situation, data type, andthe like. In an example of differences between migration processes, afirst migration process may separate data from services in a first wayand a second migration process may separate data from services in asecond way.

The automated migration tool 1530 may process and analyze the data aspart of migration 130. Alternatively, the data may be broken into aplurality of components that meet one or more criteria of datacategories associated with the web hosting platform of the commonservice architecture 100. Each component may be migrated into the webhosting platform of the common service architecture 100 and stored inthe shared storage 106. These steps may be performed using automatedsoftware tools without manual intervention.

The automated migration tool 1530 may maintain the security and accesspermission associated with the data being migrated when the data ismigrated into the shared storage 106 so that data security details, suchas access permissions, passwords, and the like required to access thedata in the web hosting platform of the server architecture 1502 may beenforced using the data segmenting and security capabilities of the datastorage 106 of the common service architecture 100. Such securityconfigurations may affect routing of the data, which is being migrated,through the load balancer 112 so that the data security may bemaintained throughout migration 130.

The automated migration tool 1530 may include access to a third partymigration tool or service. Alternatively, the third-party migration toolor service may be integrated with the automated migration tool 1530. Thethird party migration tool or service may facilitate the migration ofthird party services into the common services architecture 100. Forexample, email address book entries may be transferred into the commonservice architecture 100 using proprietary tools of the email softwareprovider. Likewise, the automated migration tool 1530 may utilize autility that supports transparent data migration to provide capabilitiessuch as throttling or pacing data movement during migration 130.

The automated migration tool 1530 may ensure secure transfer of the datainto the common service architecture 100. The automated migration tool1530 may use a marker or a save point during migration 130 to ensuredata integrity once migration 130 is over. The automated migration tool1530 may be able to roll back a migration to a particular marker (alsoknown as a save point) in case of failure during migration 130. Theautomated migration tool 1530 may also insert a marker or save pointbetween each data point. In the event of occurrence of a failure in thedata migration process, transfer of data may be initiated from the lastmarked point. In the event of a severe migration failure, the automatedmigration tool 1530 may roll back all previously performed migrationsteps.

The automated migration tool 1530 may achieve hardware independence byincorporating software capable of integrating multiple data repositoriesand hardware such as hard disks, free agents, and the like seamlesslyinto the common service architecture 100 during migration 130. This maybe important since the common service architecture 100 may includeservices pools catering to different services. The service pools may beconfigured using a plurality of servers, each of which may havedifferent configurations, hardware, processing capability, manufacturer,and the like.

In an example, a client may wish to migrate to the web hosting platformof the common service architecture 100 independently, without involvingthe client's existing web-ho sting service provider, i.e., provider ofthe server architecture 1502. This may be required when secrecy of thedata is paramount or when the client wants to utilize his or her ownresources for transferring the data. The automated migration tool 1530may provide a migration help utility to aid a client in such a transfer.An exemplary migration help utility may include a list of steps to befollowed by the client to undertake the migration into the commonservice architecture 100. The migration help utility may include ademonstration to show a client how to carry out migration 130. Forexample, a first screen of the migration help utility may list the stepsinvolved in migration 130. A next step may involve identifying the typeof migration, the hardware and software involved in the migration, andthe various errors that may occur during the migration process. Themigration help utility may also provide a list of critical issuesobserved during the migration process specifically in migrating businessprocesses.

The automated migration tool 1530 may collect information about theexisting web hosting configuration. By collecting this information, theautomated migration tool 1530 may be able to create a web hostingplatform that may match a client's needs more accurately. Theinformation of the web hosting configuration may be related to severconfiguration, network configuration, database configuration, and thelike. For example, the server configuration may include collection ofinformation related to number of CPUs, logical partitions, type of filesystem, and the like. This information may be collected using automatedtools. Alternatively, a user interface may be provided for receivinginformation about the web hosting configuration to be migrated from theserver architecture 1502. The corresponding configuration informationmay be entered by the client or by the web hosting service provider andthen used by the automated migration tool 1530 to carry out migration130.

The automated migration tool 1530 may include a software tool with anability to facilitate creation of a migration data map based on the dataand the services to be migrated. The tool may include a graphical userinterface that a client or web hosting provider may use to create amigration data and service map that may help guide and ensure compliancewith the original intent and capabilities of the web hosting accountbeing migrated.

The automated migration tool 1530 may initiate the data migrationprocess by identifying data structures representing the data and theservices to be migrated. This identification step may include loadingdata structures and generating a map of associated data. The automatedmigration tool 1530 may use a software tool to facilitate automaticidentification of the data from the data map to be transferred to thenew web hosting platform of the common service architecture 100. The mapof associated data may be modified manually to assure accuracy. Rulesfor transfer of the data may be created before initiating the transferof the data. A data migration repository may be used as a temporarystorage for analysis, recording errors, correcting exceptions, creatinga log of rejects between the server architecture 1502 and the commonservice architecture 100, and the like. The data migratory repositorymay be a part of the common service architecture 100 or may be external;that is, outside both the server architecture 1502 and the commonservice architecture 100. Finally, the migrated data may be transferredinto the common service architecture 100.

The automated migration tool 1530 may allow direct migration, phasedmigration, or parallel migration of data. Direct migration may involvemoving the existing data from the server architecture 1502 to the commonservice architecture 100 completely and running the data from the commonservice architecture 100. Similarly, the phased migration may involvemoving the data to the common service architecture 100 in segments.During phased migration, both the web hosting service of the serverarchitecture 1502 and web hosting service of the common servicearchitecture 100 may operate in parallel.

Further, migration may also involve transfer of Domain Name Server(DNS). In this aspect, the automated migration tool 1530 may include asoftware module that automatically creates a log of configurationinformation from the server architecture 1502 and implements theconfiguration information on the common service architecture 100.Alternatively, the DNS configuration setting may be applied manually byentering the required information into the common service architecture100. The DNS may be replicated in the common service architecture 100and both the architectures may be operated conditionally for a specifictime before the server architecture 1502 is removed.

Likewise, in some instances migration may include replication and/ormigration of active directory services, especially in an environmentwhere Internet and intranet reside on a single server. In such cases,the migration of active directory may be facilitated by eitherreplicating the active directory in the common service architecture 100using an automated tool or manually copying the configuration settingsinto the common service architecture 100. In another aspect, anautomated software tool may transfer the active directory residing inthe server architecture 1502 directly to the common service architecture100.

The automated migration tool 1530 may ensure the transfer of a securityrelated parameter, such as a domain password, registry key, accessinformation of the existing host, transfer of databases, SSLcertificates, version compatibility, email addresses, and the like.Failure to transfer any one of these parameters may result in failure ofmigration 130. In this case, manual intervention may be required tocomplete migration 130. Further, the automated migration tool 1530 mayallow reverse migration.

Once the migration of a website is complete, the automated migrationtool 1530 may utilize an automated testing facility to ensure fullfunctionality and configuration of the migrated website. In addition,errors detected during testing may be recorded in a log file andutilized for rectification or correction of those errors.

FIG. 16 illustrates a schematic block diagram of a migration process 130for migration of a web hosting service from server architecture 1600 tocommon service architecture 100. Migration 130 may be performed by amigration facility of the common service architecture 100 that mayinclude an automated migration tool 1530. The automated migration tool1530 may allow reverse migration. The server architecture 1600 may serveservices necessary for a specific website from a single machine.Exemplary servers, such as a server 1604 may serve a website 1504.Further, all services required by the website 1504 may be served by theserver 1604. For example, the server 1604 may be capable of handlingtwenty email address accounts and ten chat accounts for the website1504. The common service architecture 100 may serve a plurality ofcommon services from a plurality of machines to a plurality ofunrelated/unaffiliated websites. The plurality of services may beprovided by a plurality of web servers that may be grouped into aplurality of service pools based on the services offered by the servers.Exemplary service pools of the plurality of service pools may include anHTTP service pool 102, an email service pool 104 and a chat service pool108.

As mentioned above and herein, the automated migration tool 1530 mayfacilitate migration of the web hosting service from the serverarchitecture 1600 to the common service architecture 100. The servicesfound on each server 1602 and 1604 of the server architecture 1300 maybe identical or may be tailored to each specific website. The automatedtool 1530 may determine which of the services provided by each server1602 and 1604 may be mapped to a common service in the common servicearchitecture 100 and may generate appropriate service adaptationinformation (e.g. metadata, website service preferences, and the like)to facilitate servers 103 of the common service architecture 100 toadapt the common services provided by the service pools (102, 104, 108)to generate service packages that replicate the services provided by theserver architecture 1600 to the migrating websites. In an example,server 1604 may include a service that provides twenty email accountsand a low-volume e-commerce service to student website 1504. The server1602 may provide a twenty email account service and an environmentalfriendly look-and-feel chat service to nonprofit website 1510. Themigration facility 130 may use the automated migration tool 1530 andother migration capabilities to migrate hosting of the three websites tothe common service architecture 100 to adapt the common services foreach migrated website.

The configuration of the common service architecture that may resultfrom the migration shown in FIG. 16 may be as follows. The servers ofthe service pool 102 may adapt a common e-commerce service provided byservice pool 102 and a common email service provided by service pool 104to generate service package 320 that may include a twenty email accountservice and a low-volume e-commerce service with the samestudent-focused look and feel of website 1504 for migratedstudent-focused website 1504A. Further, servers of the service pool 104may adapt the common email service provided by the service pool 104 togenerate service package 322 that may include a five-hundred accountemail service with the same large business-focused look and feel ofwebsite 1510 for migrated large business website 1510A. Similarlyservers of the service pool 108 may facilitate providing a servicepackage 324 that may include a twenty email account service from acommon email service provided by service pool 104 and an environmentallyfriendly look-and-feel chat service from a common chat service providedby service pool 108. The services adapted for website 1510A may includethe same nonprofit look and feel of website 1510 prior to migration. Ineach migration example above, skins 122 and code library 120, as well asother elements of the common service architecture 100 may be utilized toprovide the adapted services that facilitate the migrates websites toappear identical to those website prior to migration. In a similar way,skins 122 and code library 120 may facilitate each web hosting clientfor each of the migrated websites to interact with the common servicearchitecture 100 using the same look and feel as the client had with theserver architecture 1300.

FIG. 17 illustrates a schematic block diagram of a migration process andfacility 130 for migration of a website hosting service from serverarchitecture 1700 to common server architecture 100 that is based on aserver cloud 1720 arrangement. As with other embodiment of the migrationfacility 130, migration 130 may be performed by an automated migrationtool 1530. The automated migration tool 1530 may allow reversemigration.

The example of FIG. 17 is similar to the embodiment of FIG. 16 in manyways. However, FIG. 17 depicts migration from a server architecture 1700that may serve the services necessary for a specific website from adedicated machine, such as server 1704 providing all the servicesnecessary for website 1504 to a web hosting architecture comprising aserver architecture that serves a plurality of common services from aplurality of machines to a plurality of [unrelated/unaffiliated]websites using a cloud computing architecture 1720. In the example ofFIG. 17, all common services are provided by the common servicearchitecture 100 from servers 103 x deployed in a server cloud 1720. Theservers 103 x in the server cloud 1720 may be logically grouped intoservice pools so that a cloud server 103 x may provide one of the commonservices and several of the cloud servers 103 x may provide the samecommon service. Alternatively, servers in the cloud architecture 1720may be configured as virtual servers, wherein a plurality of virtualservers on one physical server may be organized into a service pool asdescribed herein. To support migrating the support for servicespreviously provided by server architecture 1700 to the common serviceplatform and adapting the common service platform 100 common services toprovide individual service packages that matchup to the servicespreviously provided, the servers 103 x may be configured by informationoutput from the automated migration tool 1530 based on an assessment ofthe services offered in the service architecture 1700 prior tomigration.

FIG. 18 illustrates a schematic block diagram of an alternate embodimentof the migration process 130 depicted in FIG. 17 in which the servers103 x of the common service architecture 100 in FIG. 17 are configuredin a server grid 1820. Server grid 1820 may enable grouping of servers103 x and/or providing services as described in the embodiment of FIG.17 while taking advantage of computing and processing capabilities ofthe server grid 1820.

FIG. 19 illustrates a schematic block diagram of a migration process 130for migration of a website hosting service from server architecture 1900to common server architecture 100. The server architecture 1900 may be aone box per multiple client architecture and the common serverarchitecture 100 may be a many boxes for many clients architecture.Further, migration process 130 may be performed by an automatedmigration tool 1530. The automated migration tool 1530 may allow reversemigration. The server architecture 1900 may serve a plurality ofservices necessary for a plurality of website from a dedicated machine.The dedicated machine may be a server capable of serving all theservices required by the plurality of websites. An exemplary server suchas a server 1902 may serve website 1504. All services required by thewebsite 1504 may be served by the server 1902. For example, the server1902 may be capable of handling ten chat accounts and FTP services forthe website 1504.

In an embodiment, the dedicated machine of the server architecture 1900may have one or more substantially duplicate machines for backuppurposes. Exemplary duplicate machines may include a backup server 1902Aand a backup server 1902B where a duplicate machine may provide all ofthe services provided by the server 1902, such as email service,e-commerce service, chat service, HTTP service, FTP service, DNSservice, calendar service, and the like. Alternatively, the duplicatemachine may be a server capable of handling multiple services ofdifferent types, such as a combination of email, chat, calendar, HTTPand FTP services. The duplicate machines may restore data from theserver 1902 by creating a backup copy of the original data. This backupcopy may be stored in the backup servers 1902A and 1902B and may beprotected from potential failures of the server 1902. In case the server1902 fails, one or more of the backup severs may be used to re-create,or restore, the data of the various websites.

The common service architecture 100 may serve a plurality of commonservices from a plurality of machines to a plurality of websites usingat least one of a grid computing architecture (also referred as ‘servergrid 1920’) and a cloud computing architecture (also referred as ‘servercloud 1922’). The plurality of websites may includeunaffiliated/unrelated websites as depicted in FIG. 19 as migratedwebsite 1504A, website 1508A, and website 1510A.

The server grid 1920 may include a plurality of servers that may providethe plurality of services to the websites. The server grid 1920 maybroadly represent many networked loosely coupled computers that may acttogether to perform large tasks. Exemplary servers of the server grid1920 may include server 103A, server 103B, server 103C, server 103D,server 103E, and server 103F. The server grid 1920 may enable multipleapplications to share computing infrastructure thus may provideflexibility, power efficiency, scalability and availability, instead ofdedicated servers and storage for each website. The servers in theserver grid 1920 may be pooled and provisioned among the websites ondemand. The server grid 1920 may increase the physical resources ondemand and thus allow migration of the website hosting service from theserver architecture 1900 to the common server architecture 100.

The server cloud 1922 may include a plurality of servers that mayprovide the plurality of services to the websites. The server cloud 1922may broadly represent a plurality of shared resources, software andinformation that may be utilized by the websites. Exemplary servers ofthe server cloud 1922 may include server 103A, server 103B, and server103C. The servers in the server cloud 1922 may be shared among thewebsites on demand.

The services provided by dedicated server 1902 to the website 1504 maybe migrated to the common service architecture 100 based on anassociation of these services with aspects of the common servicesprovided by the common service architecture.

A plurality of email services provided by the server 1902 to the website1504 may be migrated with the automated migration tool 1530 byidentifying a common email service that may be adapted with the serversto provide service packages 320, 322, 324 that result in migratedwebsites 1504A, 1508A, and 1510A receiving substantially the sameservices a were provided by the dedicated server 1902 prior tomigration. The migration facility 130 may, such as through the automatedmigration tool 1530 may provide output (e.g. data, metadata, software,and the like) that may be used to provide three distinct servicepackages to each of websites 1504A, 1508A, and 1510A that matchfeatures, including the look-and-feel, of the individual servicesprovided by the server 1902 to the website 1504. Migration 130 findsservices in the first website hosting architecture (server architecture1600) that can be provided by adapting one or more common services inthe common services architecture 100 and may configure various websitepreferences, subscription packages, web hosting client accounts and thelike as part of automated migration.

FIG. 20 illustrates a schematic block diagram of a migration process 130for enabling migration of a web hosting service from a dedicatedenvironment for each client to a shared environment for multipleclients. Specifically, migration 130 may be performed by an automatedmigration tool 1530 that may enable migration of a website hostingservice from server architecture 2000 to common service architecture100. The automated migration tool 1530 may allow reverse migration. Theserver architecture 2000 may serve services necessary for a client'swebsites from a dedicated machine. The dedicated machine may be a servercapable of serving all the services required by the client's websites.Exemplary servers may include a server 2002 with dedicated memory 2030and a server 2004 with dedicated memory 2032. The server 2002 mayprovide the services that are necessary for websites owned by a client2010. Likewise, server 2004 may provide the services that are necessaryfor websites owned by client 2008.

In the example of FIG. 20, the websites owned by the client 2010 mayinclude exemplary websites as website 2012, website 2014, and website2018 that may require fifty chat accounts and FTP services for thewebsite 2012, five hundred email address accounts and HTTP services forthe website 2014, and a thousand user chat account service for thewebsite 2018. Similarly, the server 2004 may provide the necessaryservices for websites owned by a client 2008, such as website 2020 thatmay require a one-thousand transaction per day service, and website 2022that may require video upload and download/streaming services.

The common service architecture 100 may serve a plurality ofunrelated/unaffiliated clients from a plurality of shared servers 2028.In the example of FIG. 20, the plurality of shared servers 2028 mayinclude a server 103A, a server 103B, a server 103C, a server 103D, aserver 103E, a server 103F, and a server 103G that each may be any of avariety of server types including web servers, data servers, computingservers, cloud-based servers, and the like. The shared servers 2028 maybe shared among a plurality of websites, such as migrated websites2012A, 2014A, 2018A, and non-migrated websites 310 and 312. The sharedenvironment provided by the shared servers 2028 may include sharedmemory across the multiple clients 2010A, 2040, and 2042. The sharedstorage 106 may serve as the shared memory that may store data for theunrelated/unaffiliated hosted websites of the common servicearchitecture 100 clients.

As described with respect to the embodiments of FIG. 17 through 19, dataprovided by the automated migration tool 1530 may be configured toprovide specific service packages from common services hosted by thecommon service architecture 100. Alternatively, the common services maybe embodied as a plurality of software processes running on one or moreof the shared servers 2028 for adapting common services to provide theservices necessary for each client's websites. The adapted services aredepicted by service package 320 for client 2040, service package 322 forclient 2042, and service packages 324 and 324A for migrated client2010A. Alternatively, service package 320 may be provided to more thanone client, such as client 2040 and client 2042 as depicted by optionalconnection between service package 320 and client 2042. Further in thisexample, two migrated websites owned by client 2010A may receive thesame service package (e.g. website 2014A and website 2018A may bothreceive service package 324A. Such a configuration may occur when theclient 2010A has initialized a new website (e.g. 2018A) and has usedwebsite 2014A as a template. Until the client 2010A customizes theservices for new website 2018A, the adapted common services may be thesame for the two websites.

The embodiment of FIG. 20 further illustrates the flexibility of thecommon service architecture 100 by showing that a single client 2010Amay be able to access web hosting services through two or more servicepackages 324 and 324A to service his websites and/or his hostingaccount. Each service package 324 and 324A may have a differentlook-and-feel that may visually indicate to the client 2010A whichservice package, and therefore which of his hosted website(s) he isaccessing. In another example, client 2010A may access his web hostingaccount configuration and control the web hosting services available toeach of his three websites through a look-and-feel of a client interfacepanel provided through service package 154. Service package 324A mayinclude the services needed for the websites but may not allow foradministrative access to the web hosting account, thereby facilitatingclient 2010A to allow a third party or other user access to variousaspects of his website hosting with the common service architecture 100without providing full access to all aspects of his account.

The common service architecture 100 may be a cloud computingenvironment. In the cloud computing configuration, the shared servers2028 may broadly represent a plurality of shared resources, software,and information that may be utilized by the websites. A server of theshared servers 2028 may be shared among the websites on demand, such asto provide a common service through service for adapting by 1708 whendemanded by website 310, 312, and the like. The cloud computingconfiguration may enable provision of the services from the commonservice architecture 100 in the form of web-based tools or applicationsthat web hosting clients or users of the hosted websites may access anduse through a program (e.g. a web browser).

The common service architecture 100 may be a grid computing environment.In the grid computing configuration, multiple unrelated/unaffiliatedwebsites may share computing infrastructure provided by the sharedservers 2028 that may provide a flexible, power efficient, and scalablesolution for a website. The servers in the grid may be pooled andprovisioned to the websites on demand. Further, the grid computingconfiguration may increase the physical resources when required.

The common service architecture 100 may include a plurality of commonservice pools disposed across the shared servers. Each of the sharedservers 2028 may be logically associated with a service pool to improveserver utilization.

FIG. 21 illustrates a schematic block diagram of a migration process 130for migration of a web hosting service from common service architecture2100 to common service architecture 100. Specifically, an automatedmigration tool 1530 may enable migration of the website hosting service.The automated migration tool 1530 may allow reverse migration. Each ofthe server architectures may serve a plurality of common services from aplurality of machines to a plurality of unrelated/unaffiliated websites.The plurality of machines may be a plurality of web servers. Featuresand capabilities that may relate to serving a plurality of commonservices from a plurality of machines to a plurality of unrelatedwebsites may be provided by either or both common service architectures(100 and 2100) based on the descriptions of common service architectureswhich are also referred herein as new web hosting architectures.Migrating from one common service architecture 2100 to another commonservice architecture 100 may be as basic as copying information relatedto the adaptation requirements for each website from the shared datastore 106 of a first website hosting architecture to the shared datastore 106 of a second website hosting architecture and serving thewebsites to be migrated with the second website hosting architecture. Ifthe first website hosting architecture is configured into service pools,servers in the second website hosting architecture may already serve thesame common services as the servers in the first website hostingarchitecture.

Migration may alternatively include configuring the servers (2102 x) inthe first common service architecture 2100 to work cooperatively withthe servers (103 x) in the second common service architecture 100,thereby effectively increasing the number of machines available to servethe plurality of common services to the plurality of unrelated websitesthat may include the websites served by the first website hostingarchitecture and the websites served by the second website hostingarchitecture.

At least one of the common service architecture 100 and the commonservice architecture 2100 may be configured as a cloud computingenvironment. In the cloud computing configuration, the servers maybroadly represent a plurality of shared resources, software, andinformation that may be utilized by the websites. A server may be sharedamong the websites on demand. The cloud computing configuration mayenable provision of the services in the form of web-based tools orapplications that web hosting clients or users of the hosted websitesmay access and use through a program (e.g. a web browser).

At least one of the common service architecture 100 and the commonservice architecture 2100 may be configured as a grid computingenvironment. In the grid computing configuration, multipleunrelated/unaffiliated websites may share computing infrastructureprovided by the architectures for a flexible, power efficient, andscalable solution. The servers in the grid may be pooled and provisionedto the websites on demand. Further, the grid computing configuration mayincrease the physical resources when required.

At least one of the common service architecture 100 and the commonservice architecture 2100 may be configured to include a plurality ofcommon service pools disposed across the plurality of machines. Theservice pools may include one or more service-specific groups ofmachines for providing various services such as, but not limited to,email, HTML services, website generation, behavior tracking,transactional services, data access (e.g. FTP), media streaming,e-commerce, and the like. The service groups may consist of machinesthat provide one of the services provided by the architecture.

FIG. 22 illustrates a schematic block diagram of a migration process 130for migration of a web hosting service from a virtualized environmentshown as virtualized server architecture 2200 to a shared environmentfor serving multiple clients. The shared environment may be representedas common service architecture 100 as described herein. Migrationprocess 130 may be performed by an automated migration tool 1530. Theautomation migration tool 1530 may allow reverse migration. Thevirtualized server architecture 2200 may be configured to serve servicesnecessary for a client's websites from a specific virtual machine. Thededicated virtual machine may be embodied as software on a server andmay be capable of serving all the services required by the website.

The virtualized server architecture 2200 may provide virtualserver-based hosting. Virtual server web hosting may enable the webhosting provider to offer near dedicated server capabilities andperformance without the costs of individually dedicated hardware. Thevirtualized server architecture 2200 may hide physical characteristicsof the web hosting platform from the web hosting client but mayassociate one web-hosting client to one virtual server (also referred asa container).

Migration from virtual server architecture 2200 to common servicearchitecture 100 may be nearly identical to migration techniquesdescribed above, and in particular may be similar to the migrationprocess described in association with FIG. 20. Whereas the descriptionof the embodiment of FIG. 20 refers to migrating from an architecturebased on a ‘dedicated machine’ for each client's website, the embodimentof FIG. 21 refers to migrating from an architecture based on a‘dedicated virtual machine’. With the caveat that virtual machinesoperate differently than physical dedicated machines, migration from adedicated virtual machine environment may function nearly the same asmigration from a dedicated machine environment. The dedicated machineenvironment of FIG. 20 included a plurality of dedicated machines (e.g.servers) with a one-to-one mapping of a machine (2002/2004) to a client(2008, 2010). Likewise for the embodiment of migration process 130depicted in FIG. 22 there is a one-to-one mapping of a virtual machine(2208A, 2208F) to a client (2008 and 2010). Migration of data, services,and other website hosting elements from virtualized server architecture2200 may proceed using substantially the same processes as migrationfrom dedicated server architecture 2000. Therefore, the descriptions ofmigration services, features, benefits, the resulting adapted commonservice architecture, and the like are not repeated here but instead aredescribed with respect to FIG. 20.

The common service architecture 100 may be configured as a cloudcomputing environment. In the cloud computing configuration, the sharedservers 2028 may broadly represent a plurality of shared resources,software, and information that may be utilized by the websites. A servermay be shared among the websites on demand. The cloud computingconfiguration may enable provision of the services from the commonservice architecture 100 in the form of web-based tools or applicationsthat web hosting clients or users of the hosted websites may access anduse through a program (e.g. a web browser).

The common service architecture 100 may be a grid computing environment.In the grid computing configuration, multiple unrelated/unaffiliatedwebsites may share computing infrastructure provided by the sharedservers 2028 that may provide a flexible, power efficient, and scalablesolution for a website. The servers in the grid may be pooled andprovisioned to the websites on demand. Further, the grid computingconfiguration may increase the physical resources when required.

The common service architecture 100 may include a plurality of commonservice pools disposed across a plurality of servers. The plurality ofservice pools may provide the plurality of services to the websites. Theservice pools may include one or more web servers. The service pools maybe logically grouped on the basis of service offerings. The servicepools may include one or more service-specific groups of web servers forproviding various services such as, but not limited to, email, HTMLservices, website generation, behavior tracking, transactional services,data access (e.g. FTP), media streaming, e-commerce, and the like. Theservice groups may consist of servers that provide one of the servicesprovided by the common service architecture 100.

FIG. 23 illustrates a schematic block diagram of a migration process 130for migration of a web hosting service from web hosting architecture2300 to web hosting architecture 2304 wherein a virtual network, such asan exemplary virtual network 2302, may be used during migration process130. FIG. 24 illustrates exemplary request-response cycles for websitesduring migration from server architecture 2310 to common servicearchitecture 100. To the extent that the descriptions of FIGS. 23 and 24are the same, references to both or either figure will be used below. Inan example, web hosting architecture 2300/2310 indicates that thedescription may be the same for either FIG. 23 or FIG. 24.

An automated migration tool 1530 may be used for migration process 130.The automated migration tool 1530 may allow reverse migration. Thevirtual network 2302 may be used to facilitate keeping a plurality ofwebsites active during movement of Internet Protocol (IP) addresses fromthe web hosting architecture 2300/2310 to the web hosting architecture2304/100. Any of the web hosting architectures 2300/2304/2310/100 may beany one of a grid computing environment, a cloud computing environment,an environment in which common services are grouped together as aservice pool, or an environment in which shared servers are used toprovide services to a plurality of unrelated/unaffiliated websites. Theweb hosting architectures 2300/2304/2310/100 may also be a combinationof the above environments.

Owing to the general structural constraints of Internet-style routing,migration techniques may be based on a batch process that requirestaking down a batch of URLs (e.g. 255) to migrate even one URL. Therouting limitation relates to a constraint that a URL cannot beadvertised as existing at two different physical places at the sametime; therefore, changing the physical location of even one URL mayresult in various URLs within the same range of 255 URLs beingtemporarily affected until the migration of the URL is completed.Therefore, batch-based migration techniques may affect up to as many as255 URLs at a time generally due to how internet routers handle IPaddresses.

The automated migration tool 1530 may work cooperatively with a virtualnetwork-based migration technique that may overcome routing limitationsof batch-based migration while supporting individual IP addressmigration. This technique may include setting up a proxy (e.g. virtualLAN) for all IP addresses to be migrated and managing routing based onthe migration status.

With this technique, migration may occur on a URL-by-URL basis withoutother URLs being affected. In addition, new physical IP addresses may bebroadcasted one-by-one as migration proceeds. With the use of a virtualnetwork during migration, internet access to hosted websites may accessthe old physical locations before migration, the virtual network duringmigration, and the new physical address after migration as depicted inFIG. 23.

Referring to FIG. 24, the virtual-network migration technique mayfacilitate the migration of old content from an Original Web Host (OWH)that hosts site A (WCA) and site B (WCB) to the common servicearchitecture 100 Web Host (NAWH) through a Virtual LAN or VPN. Althoughsite A and site B may be hosted by the same OWH, each site may be servedby a separate server and located a physically disparate locations.Because the virtual network-based migration techniques of the commonservice architecture 100 may allow clients to completely orincrementally implement a migrated website on a web host of the commonservice architecture 100, the web pages and services to be migrated maybe operated in parallel utilizing both the original web host and the newarchitecture web host during migration, thereby mitigating the datadisruptions normally associated with batch-based migration.

Virtual networking may facilitate improved web hosting migration bysupporting assigning one or more addresses to migrating content withoutexternally binding the addresses to a physical interface. Such aconfiguration may be useful, when multiple occurrences of the webservers are bound to different addresses. Virtual networking or IP mayalso be referred to as ‘circuitless’ or loopback interfaces that may beused herein without deviating from the scope of the invention.

Virtual networking may be used where multiple paths are required forfacilitating communication between the local gateway and the web server.Virtual networking may also facilitate load balancing, fault toleranceand information redundancy for 24×7 operations. Referring again to FIG.24, the original web-hosting content at site A and Site B may holdcontent for responding to a web request. A Virtual Private Network (VPN)may be established in between the original web-hosting server and thenew architecture web host. Subsequently, the migration facility 130associated with the common service architecture 100 may initiate amigration process for transferring content from WCA and WCB to the newarchitecture web host (NAWH). The entire content may be transferred fromWCA to NAWH. Alternatively, the entire content WCB may be transferred tothe NAWH with one section of content from WCA being transferred to theNAWH. Another alternative may be that the entire content of WCA may betransferred, while only partial content of WCB may be transferred.

In the embodiment of FIG. 24, WCA content may at most be partiallymigrated and WCB content may be fully migrated. A web request for hostedweb content may be received at the original web host (OWH) for eitherWCA or WCB. The request may be forwarded to the migration routing serverat NAWH over VPN. The NAWH may determine if the request has beenmigrated; if so, then the NAWH may furnish the necessary content inresponse to the request. If a web request is received for WCA contentthat has not been migrated to the NAWH, then the request for WCA contentmay be send back over the VPN to a server in the OWH for gathering theWCA data and responding to the web request. If the request is for WCBcontent then the request may be forwarded to servers in the NAWH forgathering the migrated WCB data out of the shared storage 106 andresponding to the web request. The WCB response may be forwarded overthe VPN before being sent back to the web requester.

Referring again to FIG. 24, to facilitate reduced or ideally zero downtime for a website being migrated to the common service architecture100, migration may take advantage of migration features of the commonservice architecture 100 that may allow, among other things, partialdata transfer and backup, as well as partial website (e.g. URL,individual service, etc.) migration without interruption of service ordata access. Partial data transfer and backup may allow a portion of awebsite content to be relocated into a shared storage 106 of the commonservice architecture 100 so that user access to content provided throughthe website (for example) may be directed to either the original datasource or through the common service architecture 100 to the sharedstorage 106.

Similarly, partial website migration or service-specific migration mayenable migration of services over time. In an example, email accountsmay be migrated before other portions of an acquired web-hostingclient's account. In this way, the migration may be accomplished inone-step or in a multi-step process where services may be movedseparately. The service pools of the common service architecture 100 mayprovide a backup of the migrating services.

The virtual-network migration technique shown in FIG. 24 may facilitatethe migration of old content from an original web host serverarchitecture 2310 that hosts a websites 2312 and 2314 to the web host ofthe common service architecture 100 through a virtual network 2302. Thevirtual network 2302 may be a virtual private network. Although websites2312 and 2314 may be served by server architecture 2310, each site maybe served by a separate server and located at physically separatelocations. Because the virtual network-based migration techniques mayallow clients to completely or incrementally implement a migratedwebsite on a new web host, the web pages and services to be migrated maybe operated in parallel utilizing both the original web host and the newweb host during migration, thereby mitigating the data disruptionsnormally associated with batch-based migration.

Virtual networking may facilitate improved web hosting migration bysupporting assigning one or more addresses to migrating content withoutexternally binding the addresses to a physical interface. Such aconfiguration may be useful when multiple occurrences of web servers arebound to different addresses. Virtual networking or VPN may also bereferred herein as ‘circuitless’ or loopback connections withoutdetracting from the scope of the invention.

Virtual networking may be used, for example to facilitate using multiplenetwork communication paths for facilitating communication between alocal gateway and a web server. Virtual networking may also facilitateload balancing, fault tolerance, and information redundancy for 24×7operations. Referring again to FIG. 24, the original web hosting contentat website 2312 and website 2314 may hold content for responding to aweb request. A VPN may be established between a server in the serverarchitecture 2310 and a server in the common service architecture 100.Subsequently, the automated migration tool 1530 associated with thecommon service architecture 100 may initiate a migration process fortransferring content from the websites to the common servicearchitecture 100.

In the example of FIG. 24, website 2312 content is at most partiallymigrated and website 2314 content is fully migrated. An Internet requestfor hosted web content may be received at the original web host 2310 foreither website 2312 or 2314. The request may be forwarded to a migrationrouting server 2318 over a virtual network 2302. The migration routingserver 2318, which may be one of the servers 103 or load balancers 112of the common service architecture 100 may determine if the request hasbeen migrated; if so, then the common service architecture 100 mayfurnish the necessary content in response to the request. If a webrequest is received at the migration routing server 2318 for website2312 content that has not been migrated, then the request for website2312 content may be sent back over the virtual network 2301 to a serverin server architecture 2310 for gathering the website 2312 data andresponding to the web request. If the request is for 2314 content, thenthe request is forwarded to servers in the common service architecture100 for gathering the migrated website 2314 data out of the commonstorage 106 and responding to the web request. The website 2314 responsemay be forwarded over the virtual network 2302 before being sent back tothe web requester. Alternatively, the common service architecture 100may respond directly to the web requester.

The web hosting platform 100 may include an analytics facility 134 foranalyzing data for predicting and managing the retention of the client,mapping of various products that may be offered to the clients,conducting data mining, conducting predictive analysis, and the like.The analytics facility 134 may facilitate applying various types ofstatistical analyses on data that is obtained from a variety of sourcesincluding client interactions with the web hosting platform 100,products available to clients, product sales performance data, productroadmaps, client retention data, competitive offerings, acquired entitydata, third party data, and the like. A key source of data is the largediversity of web hosting clients. Web hosting client-related data mayinclude data provided by a client during registration for web hosting.This client provided data may include client details such as individualidentification (e.g. user name), organization with which the clientmaybe associated (e.g. client employer), physical location, subscribedweb hosting plan, prior web hosting experience, prior web hostingprovider, and the like. We will discuss associations of the analyticsfacility 134 and client-related data in detail below.

The web hosting platform 100 may be substantially based on clientsubscriptions. Survival analysis for a subscription business may bebased on an application of statistical models from medicine. Inmedicine, survival analysis is based on using statistical tools to lookat survival rates of patients against a control group. Kaplan-Maierstatistical tools are used in medicine, and similar techniques may beapplied to look at survival rates of web hosting clients. Survival isgenerally represented as a mathematical curve starting at 100% anddeclining over time, such as a number of subscription days, months, oryears on the new web hosting platform 100. The large populate of clientsthat use the new architecture web hosting platform 100 may facilitatebuilding survival analysis applications based on those clients and thetime clients remain subscribed to the platform to see how long theysurvive and why they survive. Longer surviving clients mean longer termbilling. To access the massive amount of client-related data forsurvival and retention analysis, the analytics facility 134 may pluginto the OSS of the new architecture web hosting platform 100 to stripoff information about clients, client patterns and behavior for use withsurvival analysis facilities, including black box type facilities. Withthe analytics facility 134, one can view stacked indexes of survivalcharacteristics based on survival rates for a variety of clientparameters, such as client origin. In an example clients may be sourcedvariously from specific geographies (e.g. Russia), from referrals (e.g.GOOGLE internet/web search results), from acquisitions, and the like.The stacked index may show retention characteristics by origin tofacilitate focusing client retention activities.

Hazard analysis facilitates determining the big driving factors forclient retention or loss. Activity patterns of clients can be used asco-variants in hazard analysis for retention-factor detection. Exampleclient patterns may include frequency of contact, price activity, domainregistration, and the like. In an example, clients who have notregistered a domain in more than six months may appear in a group ofhigher hazard clients than those who have registered a domain within thepast six months.

The analytics facility 134 may also be beneficial in product management,marketing, sales, and development. The analytics facility 134 mayinclude product mapping/confidence calculation that may be presented ona three-dimensional (3D) product map. Such a 3D map may includedistances on X, Y and Z dimensions for all customers for all customerproducts, thereby determining client data-related distances betweencorrelated products. A large scale implementation of the newarchitecture web hosting platform 100 may include more than one-millionclient and may also include a large number of products some of whichdiffer only by price while others differ substantially in functionality,features, and the like. With a very large number of clients and a largenumber of products, a product mapper may provide insight into whichproducts are interesting to which customers. A product mapper may alsoenable developing insight about potential interest in products that havea very small number of users by determining its proximity to a productwith a large number of users. Even when products look completelyunrelated, the product mapper algorithms look at usage patterns ofcustomers who buy one product or another and determine “distancerelevance” of one product to another. One potential result of theproduct mapper algorithms is clustering of products along dimensions notreadily apparent from the product itself. Clustering may enabledevelopment of product profiles of related products that may suggestcertain product bundling options and/or co-marketing approaches. Byanalyzing closely clustered products, a product that is selling well toa small group of clients may be able to be positioned to be sold to alarge group of clients who are buying another product in the cluster.

The analytics facility 134 may also facilitate turning independentcustomer-by-customer profiles into sales and product offeringopportunities. For any given product, an odds calculator facility usesinformation about all clients who bought the product and all clients whodid not to determine the odds of selling the product to each customer.The odds calculator then fits an algorithm into that odds calculation sothat there is a better than even chance of making a sale. Using analgorithm that attempts to make large numbers of predictions fromrelatively small sample data sets, such as a random forest algorithmfrom computer gaming science, the odds calculator generates a massiveprediction grid of all customers (e.g. X axis) and all products (e.g. Yaxis)). Suitable algorithms may include the following capabilities:produce highly accurate classifications; handle large number of inputvariables; estimates the importance of variables for classification;estimates missing data; maintains accuracy when a large portion of datais missing; facilitates computing proximity of data classes fordetecting outliers and for visualizing the data; and facilitatesexperimental detection of interaction of variables. Techniques for thisuse may include homogeneous tree algorithms that achieve diversitythrough randomization, and heterogeneous combinations of multiple treealgorithms, such as mean margins decision tree learning algorithms,standard entropy-reducing decision tree learning algorithms,multivariate decision trees, oblique decision trees, perceptron decisiontrees, and the like. Alternative to learning decision tree typealgorithms include multiclass support vector machines, and algorithmsthat facilitate predictive analysis of current and historical facts tomake predictions, such as classification tree algorithms, regressiontree algorithms, Classification And Regression Tree (CART) algorithms,CHi-squared Automatic Interaction Detector (CHAID) algorithms, QUESTalgorithms, C5 algorithms, and boosted trees algorithms. Client-relateddata that overlaps between a customer who bought the product and one whodid not is then used to determine the odds that another customer withthat same overlapping data will buy the product. This produces an oddsratio for that represents the likelihood that each customer will buyeach product. This can be presented in an odds ratio stack for a givencustomer that facilitates determining high odds ratio for similarcustomers buying the product. Over time, the sales results of productsthat are offered for sale to similar customers are factored into theresults and the odds are recalculated. Because the new architecture webhosting platform 100 has a massive number of clients 101 (overone-million), the existing sales data turns out to be a generally usefulfor fitting an algorithm as described above. Being based on computergaming and science concepts, the odds calculator may automaticallygenerate and fit an algorithm that presents measurable odds that arereflected by the actual client sales data. In addition, because the oddscalculator method includes feedback based on on-going sales attempts thealgorithm that was initially fit to the existing sales data isautomatically adjusted and refined as sales data is provided. Such atool may be useful to help agents 118 pick more products to offer forsale to many customers.

The analytics facility 134 may operate on a variety of data types thatmay be obtained from a variety of sources. Data may be acquired via adata mining facility, accessed directly by the analytics facility 134,through third party data sourcing facilities 128, and the like. Data maypreferably be obtained through the OSS facility because it may providebetter analysis as it includes data from a large pool of web hostingclients 101. Acquisition activity is also another notable source of datafor various analytics processing. Newly acquired entities often haverich data related to their clients, web hosting products, performance,and the like. Evaluating potential acquisition targets is oneapplication of the analytics facility 134 so data that may be obtainedfrom or about potential acquisitions may facilitate decisions about theacquisition and potential impact on existing clients 101.

Predicting and managing client 101 retention may benefit from clientretention analysis based on various survival analysis techniques thatmay be borrowed from the medical and actuarial fields and applied to thesubscription-based web hosting platform business model. In asubscription-based business model, the attrition rate of the clients 101has sometimes been related to factors such as client dissatisfaction,cheaper and/or better offers from the competitors, more successful salesand/or marketing by the competitors, or reasons related to the clientweb hosting need “life” cycle. Thus, by analyzing the survival rate ofthe clients 101 in a subscription-based business model, preventivemeasures may be taken beforehand to retain clients. While the webhosting platform client agreement is predominantly subscription-based,other subscription-based businesses may benefit from similar survivalanalysis techniques, such as mobile phone networks, computer securityservices, data backup services, mobile add-on services, and the like.

The analytics facility 134 may facilitate applying survival analysis toidentify the key factors in survival and attrition of clients 101 andthus, enable retention of the clients. The survival analysis may allowpredicting when client accounts will turn, how long the clients 101 willstay, rates of churn, and the like. Survival analysis may be associatedwith a branch of statistics that may involve the modeling oftime-to-event data which includes the study of durations between events.A few exemplary web hosting platform-related events may include loss ofa client 101, addition of a client 101, renewal of a client 101, upgradeof a client account, suspension of a client account, default of anaccount, and many other experience of interest associated with theclient 101. Survival analysis as applied to a subscription-basedbusiness model may generally include the use of a survival function torepresent the probability of the occurrence of a client-retentionrelated event. A suitable survival equation may be denoted as:‘S(t)=Pr(T>t)’ where “S” is the probability of survival at a point intime represented by “t”; t is a future point in time or perhaps a lengthof time, T denotes the time to failure (or some other action thatterminates survival), and “Pr” denotes a probability function. Thus, thesurvival function may indicate the probability that the time of failureis later than some specified time; alternatively it may indicate theprobability that a client 101 will remain a client beyond a future pointin time “t”.

To facilitate client retention management benefits, the survivalanalysis techniques described herein and elsewhere may facilitate studyof the extent to which factors that are normally associated with theclients have affected some existing clients' survival duration; therebypotentially being useful in predicting the survival time for otherclients 101. By analyzing a wide variety of client-related data forsurviving clients as well as lost clients, performing survival analysismay facilitate determining key factors that may be involved in retainingclients 101. If an association between a factor and client retention maybe established with a good confidence level, then the factor may beconsidered a key factor of client retention. Further analysis may beperformed to determine if there is a one or more clients 101 to whom thefactor is considered a key retention factor. An example of a key factormay include a rate of positive support events reported by the client101. Survival analysis, such as a basic survival curve may be appliedagainst any client-related parameter (e.g. survival factor) or acombination thereof to determine aspects related to client retentionbased on that parameter.

Further, the survival rate analysis facility may be configured tooperate as a black box that may allow any pertinent data parameter to beanalyzed for its relationship to client retention. For assessing clientrelated data parameters, such a client retention analysis black box maybe interfaced with the OSS facility of the new architecture web hostingplatform 100 to directly analyze any type of client information that isaccessible through the OSS. The objective of such a deployment of thesurvival rate analysis black box may include ongoing client retentionparameter analysis. In an example of a black box application of thesurvival rate analysis facility, client origin may be analyzed againstclient survival to determine one or more relationships between clientretention and origin. In this way, a user of the survival rate analysisfacility may determine the expected survival rate over time of clients101 who were originated through affiliate referrals. A low survival ratemay indicate that affiliate referrals are not a good source of long termclients 101. The black box could be used to determine an associationbetween client location and retention so that retention efforts could beproperly directed locations of interest that have undesirable retentionrates. The results may be presented as a stacked index of survivalcharacteristics based on survival rate and client location or origin.

More generally, a black box analysis facility based on a survival ratemodel may be useful in determining the interaction of stimuli, clientcharacteristics, decision process, client responses, and the like withretention. Such an analysis may allow for the assessment of controllableitems, such as stimuli and items that are outside of the control of theweb hosting facilitator, such as client characteristics and decisions.Examples of some facets of elements that could be analyzed forassociation with client retention include: stimuli, such as marketingstimuli, the 4 marketing “Ps” (product, price, place, and promotion);environmental stimuli which may include factors like economic,technological, political, cultural, demographic, and natural; clientcharacteristics which may include attitudes, motivation, perceptions,personality, lifestyle, knowledge; decision factors which may includeproblem recognition, information search, alternative evaluation,purchase decision, and post-purchase behavior; client responses whichmay include product choice, brand choice, dealer choice, purchasetiming, and purchase amount.

The client survival rate based on one or more parameters for a givenperiod of time that extends into the future may indicate the probabilitythat a client 101 that is associated with the one or more parameter willrepurchase or re-subscribe in that particular period given the currentproduct offering.

The platform may be used to build a database of survival data based onanalysis of current client survival and retention. A database ofsurvival data may be utilized to track historical survival and retentionanalysis that may be useful in further understanding details related toa lack of survival of former clients as new approaches for retention aredeveloped. In addition, the database may be used to predict the survivalor retention of the same client set for a new or different businessmodel or product line. The stored survival data may further allowconducting an analysis of the survival or retention of the same set ofclients 101 at different time frames.

Generally, survival rate may be a measure of lifetime related to anevent, or of a length of time until/from the occurrence of an event.Survival rate analysis results may provide an indication and/or aprobability of how much longer a client 101, or a group of clients 101,may be retained after an event takes place (e.g. acquisition of acompetitive web hosting entity, increase/decrease in prices, and thelike). Therefore, modeling events within a survival analysis facilitymay help with client retention efforts. It may also provide someestimate of the cost (e.g. in lost recurring subscription revenue) oftaking an action. This may be useful in comparing a projected benefitfrom taking the action (e.g. increasing subscription revenue byincreasing subscription rates) against the projected loss of clients 101due to the action. Survival analysis may also be useful in projectingsubscription revenue over time to help in establishing timing forcertain events. In this way, taking an action that may cause ameaningful reduction in subscribers may be timed to occur when newsubscriber rates are increasing to provide some offsetting revenue.

The survival analysis may involve various techniques including, but notlimited to, Kaplan-Meier, Failure rate, Accelerated failure time model,Censoring, hazard function, discriminant analysis, multivariateanalysis, logistic regression, rough data models, genetic programming,and others. The Kaplan-Meier analysis is a technique that involves thegeneration of tables and plots related to survival analysis based onevent history data. The Kaplan-Meier analysis may be utilized tointerpret data relating to survival analysis, evaluate the time periodof association of a client (e.g. client subscription term), and toanalyze financial data for evaluating sub-business, i.e., monthlyrecurring payments. Further, the plot of the Kaplan-Meier analysis mayinclude depicting the survival data as a series of horizontal steps ofdeclining magnitude which, when a large enough sample is taken,approaches the true survival function for clients 101 under the study.The value of the survival function between successive distinct sampledobservations may be assumed as constant. With two different factors, twodifferent Kaplan-Meier curves may be obtained for a client 101. The twodifferent curves may be compared through a Log-rank test which is usedto compare the survival distributions of two samples.

Another form of analysis that may be applied to new web hosting clientretention related data may include failure rate analysis. Failure rateanalysis helps in understanding factors that impact a frequency ortime-to-failure of an engineered system (e.g. a hardware component). Afailure rate may be expressed as failures per hour and therefore isdependent on the passage of time. As a system ages, the predictedfailure rate is likely to increase because sample data from a populationof similar systems will include a larger number of failures than when asystem is young. Therefore, it is often the case that a failure rate ofa system in its fifth year of service may be many times greater than itsfailure rate during its first year of service. Further, the failure rateanalysis may be utilized to identify a probability of a system failingat any given point in time. Alternatively, one can predict a time when agiven system is likely to fail. When failure analysis is applied to webhosting subscription data, one may predict when any given client 101 orcategory of client may stop renewing a web hosting subscription. Certainmeasurable activities (e.g. visits to a client's hosted web content orweb pages) may be useful in determining if a web hosting client 101 maybe more likely to renew and therefore extend the ‘failure rate. Renewalrates of similar clients 101 may also help in understanding when aclient is likely to ‘fail’ to renew.

For complete observation of a client 101, an ideal client retentionanalysis may include all of the time from when the client 101 firstsubscribes to the web hosting platform services until the time that theclient 101 disassociates from the web hosting platform. However, clients101 engage and disengage with the platform on any given day so such ananalysis, while ideal, may lead to an indefinite study due to waitingfor an event associated with the client to occur (e.g. disengaging withthe platform). Therefore, instead of conducting the survival analysisfor each client 101 for an indefinite time, the analytics facility 134may conduct the survival analysis for a portion of clients 101 over afixed time interval. However, survival analysis for a particular timeframe may not give the complete data regarding the clients and thus maylead to left and right censoring of the clients. The right censoring mayoccur when a client 101 disassociates with the web hosting platform 100before the end of the survival analysis time frame. The left censoringmay occur when the client 101 disassociates with the web hostingplatform 100 before the survival analysis time frame begins. Inembodiments of the invention, the analytics facility 134 may employproportional hazards models to overcome the left and right censoring ofthe clients 101. In examples, the proportional hazards model may be Coxproportional hazards model.

The survival of a client 101 may be characterized by other statisticalfunctions including a hazard function. A hazard function may be usefulin helping to identify reasons for failure by organizing factors thatmay contribute to loss of a client 101 based on relevance of thefactors. Each factor, event, client data parameter, and the like may besubjected to a hazard analysis to determine its contribution to clientretention. A hazard function may be denoted by the mathematical functionh(t) or λ(t) in various survival analysis algorithms. The hazardfunction may be defined as an event rate at time ‘t’ that is conditionalon web hosting client survival until time ‘t’ or later (mathematicallyT≧t). In terms of how it may be used in web hosting client retentionanalysis, it may predict the instantaneous rate of change of theprobability that a client 101 will not continue as a client at time ‘t’based on the requirement that the client 101 was retained until time t.As known in the art, a formula for calculating a hazard of an event canbe depicted as:

${{\lambda (t)}{t}} = {{\Pr ( {t \leq T < {t + {t}}} \middle| {T \geq t} )} = {\frac{{f(t)}{t}}{S(t)} = {- \frac{{S^{\prime}(t)}{t}}{S(t)}}}}$

Therefore, the hazard function may be utilized by the analytics facility134 to identify and potentially rank reasons for failure. The hazardfunction may also use factor analyses and/or other statistical analysesto organize client-retention factors based on their relevance. Thefactors may correspond to the parameters associated with the web-hostingclient subscriptions. The statistical analyses may include, without anylimitation, analysis of covariance (ANCOVA) and factor analysis. TheANCOVA is a general linear model and has a continuous outcome variableand one or more factor variables (qualitative). ANCOVA is treated as amerger of analysis of variance and regression for continuous variables.The ANCOVA tests whether certain factors have an effect on the outcomevariable after removing the variance for which quantitative predictors(covariates) account. The factor analysis is a collection of methodsused to examine how underlying constructs influence the responses on anumber of measured variables. As known in the art, the factor analysesare of two types: Exploratory Factor Analysis (EFA), which attempts todiscover the nature of the constructs influencing a set of responses,and Confirmatory Factor Analysis (CFA), which tests whether a specifiedset of constructs is influencing responses in a predicted way.

In an example, the hazard function analysis may allow predictions andanalysis of the financial impact of mergers and acquisitions, impact ofnew product offerings, various promotion schemes, and the like. Mergersand acquisitions may include acquiring individuals that have their ownwebsites, corporate houses, students having their own web pages andwebsites, non-profit organizations, and the like. Analysis of thesurvival of clients 101 on the basis of the new types of offerings mayinclude analyzing the introduction of new product lines for the clients101, new features in the products, combo packs of different products,additional discounts and schemes for a limited period, and providingfree trial options. Analysis of the survival of clients 101 based onvarious promotion schemes may help identify if promotion schemes impactclient retention, such as direct marketing; promotion offerings based onprice, product characteristics, client, and location; and identifyingadditional product needs for existing clients and offering products tothem. The hazard functions may also allow implementation of proportionalhazard models that may facilitate further prediction of potential impacton client retention when a covariate is increased (e.g. more promotion,larger acquisition, etc.). In addition, the hazard function may allowimplementation of conditional failure rate to augment client retentionassessment.

The analytics facility 134 may facilitate survival analysis through theuse of discriminant analyses. The discriminant analyses may includeunivariate analysis and multivariate analysis. The univariate analysismay allow classification of data into two sets using a discriminantequation. In an example, the two sets may be the retained clients andthe lost clients. The discriminant function may be modeled in computersoftware for classifying the clients 101 into one of the two sets.Further, the univariate analysis may also be useful in predicting theclients 101 who may fall into the lost category and hence, timelycorrective action may be initiated for retaining those clients 101. Themultivariate analysis may allow modeling of a discriminant equation intomore than two sets: retained clients; lost clients; and uncertainclients. The discriminant equation may be utilized for classifyingclients 101 into one of the sets, which may be modeled. Further, theclassification of clients 101 in different sets may facilitateunderstanding of the client behavior. Also, it may allow prediction ofclient behavior based on the earlier obtained data.

The analytics facility 134 may include implementing survival analysiswith logistic regression model. A logistic regression model is a type ofpredictive model that may be used when a target variable is acategorical variable with two categories. In an example, the twocategories may be client retained/client lost or client purchasesproduct/client doesn't purchase the product.

The survival analysis may be implemented by rough data models. Thismodel may involve partitioning of the whole data set and furtherordering the set elements of the partition based on some cumulativeparameters.

The survival analysis may be implemented by genetic programming. Thisapproach may involve finding a complex equation that may define a dataset in the best possible manner. The genetic programming may further beutilized in analyzing client behavior and identifying strategies forclient retention.

The survival analysis may be utilized by the analytics facility 134 forother applications other than identification of client retention. Theother applications of the survival analysis may include, withoutlimitation, reinforcement strategy. The system may estimate the timingof a client 101 leaving the system and may also allow creating astrategy for retention of the client 101. The retention strategies maybe modeled around ‘the 4 Ps’—product, price, place, and promotion. Theretention strategies may also be modeled around ‘7 Cs’—Connection,Concurrency, Comprehension, Communication, Conceptualization,Collaboration, and Collective Intelligence. The other applications mayinclude designing an acquisition strategy, identifying the timing foracquisition, and the like. The applications may also include comparisonsof the survival and/or hazard strategy. The other applications may alsoinclude allowing companies to develop client loyalty and treatmentstrategies to maximize the value of the existing clients. Further, fornewly acquired clients, the survival analysis may help companies developstrategies to increase the desired pool of clients.

Further, the new architecture web hosting platform 100 may offer avariety of products to current and prospective web hosting clients 101.The analytics facility 134 may be utilized by a facilitator of the newarchitecture web hosting platform 100 in analyzing attributes associatedwith current and new products to ensure offering products that arehighly likely to be desirable by clients 101. A web hosting platformfacilitator may use the analytics facility 134 to create two dimensional(2D) or three dimensional (3D) maps of product spaces that may depictproducts and their distances from one another in a clientdata-dimensional space. The product distance maps may show differenttypes of products at a relative distance with each other. The distancebetween the different products is indicative of a degree of commonalityalong one of the client data-dimensions. For a given client datadimensional space, the distance between various products may indicatepotential associations among products that otherwise may be functionallyquite different. In an example, a domain privacy product may be found tohave properties that make it desirable to clients 101 who own a web pageoptimization product based on the 3D proximity of the two products.

Referring to FIG. 28, which depicts a 3D mapping of certain productsoffered through the new architecture web hosting platform 100, thevarious products B, C, D, E, F, G, and H may be depicted so that therelative size of the product outline and text is indicative of theproximity to the comparison product A. The relative size of the producticon compared to product A is indicative of the similarity of theproduct to product A as measured along the client data dimensional axes.In the example of FIG. 28, product A may share more common attributeswith product B as compared to product C. Therefore, the distance betweenproduct A and product B will be relatively smaller than between productA and product C. Similarly, product A may share more in common withproduct H than with product E. Therefore, the distance between product Aand product H will be smaller than between product A and product E.

The analytics facility 134 may utilize the 3D maps to relate clients 101using those mapped products. Thus, in the example, where the distance ofproduct A with product B is less than from product A to product C, theclient 101 using product A may share more attributes with the client 101using product B as opposed to the client 101 using product C. Similarly,a user may use the analytics facility 134 to generate 3D maps thatanalyze the similarity between the products.

The analytics facility 134 may utilize various 3D map formulationtechniques including, but not limited to, Euclidean distance,Mahalanobis distance, Hamming distance, and Maximum norm. As known inthe art, the Euclidean distance is the ordinary distance between twopoints, which may be measured with a ruler, and is determined by thePythagorean formula. The “Mahalanobis distance” is a metric that isbetter adapted than the Euclidian distance to settings involvingnon-spherically symmetric distributions. It is useful when multinormaldistributions are involved. The Hamming distance is a concept used ininformation theory and measures the minimum number of substitutionsrequired to change one product into another or the number of errors thattransformed one product into another.

The 3D maps may facilitate different types of product clusters and theassociated clients. In different embodiments of the invention, theclustering may be, without limitation, hierarchical clustering,partitioned clustering, subspace clustering, correlation clustering, andthe like. The clustering may facilitate market research related toclusters associated with the clients 101. The clustering may furtherfacilitate positioning of products in the market and offering newproducts to the clients 101. Further, the clusters may be based onclients, products, price, and the correlated products. The clusteringmay further allow identifying related clients to offer new products andanalyze products to generate overlap among users of two products. Themeasure of commonality in the overlap may give the related productinformation that may facilitate better sales.

The 3D maps may facilitate analysis of the client portfolio. The 3D mapsmay allow creation of product maps for specific clients, creation ofproduct maps based on price of products, and creation of product mapsbased on the correlated products.

The 3D maps may facilitate creation of product indices. The productswith a large amount of information may form the central index for otherproducts. The product indices may facilitate association of differentproducts with indexed products. The product indices may furtherfacilitate bundling of products based on distance and client dimensions.

The 3D maps may facilitate identification of characteristics for buyinga product. The identification of characteristics may be facilitated byapplying random forest algorithm. This algorithm may include thefollowing steps: Step 1—Create a plot for client 101 from 1 to 100,000on the X axis and every product on the Y axis; Step 2—Analyze the datato identify clients 101 who purchased versus those who did not todetermine the overlap and the odds that another client 101 will buybased on their similarity; Step 3—Identify the odds for selling a givenproduct; Step 4—If something did not sell, go back and recalculate theodds; Step 5—Apply iteratively to refine the algorithm until asuccessful model emerges; and Step 6—Use optimization techniques foridentifying the best possible solutions. Different optimizationtechniques may be utilized for identifying best possible solutions. Thedifferent optimization techniques may include, without limitations,genetic algorithms, simulated annealing, tabu search, artificial immunesystem, particle swarm optimization, intelligent water drops, ant colonyclustering methods, and the like. The optimization parameters mayinclude, without any limitation, brands associated with the products,price of the products, type of products, product association (howclosely two products are related), and client retention. In examples,the product association parameter may be used in creating productassociations for selling associated products.

The analytics facility 134 may utilize a data mining facility as aClient Relationship Management (CRM) tool to understand the behavior ofthe client 101. In The data mining facility may conduct affinityanalysis to discover co-occurrence relationships among activitiesperformed by (or recorded about) a specific individual client or groupsof clients. The affinity analysis may be used to perform the marketbasket analysis, in which retailers seek to understand the purchasebehavior of clients 101. The market basket analysis might tell aretailer that its clients often purchase bread and butter together, soputting both items on promotion at the same time would not create asignificant increase in profit, but a promotion involving just one ofthe items would likely drive sales of the other. In another embodimentof the invention, the data mining facility may be used to identifyclient satisfaction parameters. In examples, the client satisfactionparameters may include, without any limitation, overall satisfactionwith the deal, sales experience, product delivery experience, productexperience, product servicing, relationship experience, complaintresolution/grievance handling, and collection experience.

The data associated with the activities of the client 101 may beobtained for data mining through various channels. FIG. 25 illustrates asystem for data mining the data associated with the activities of theclients 101. The system illustrated in FIG. 25 includes a common datastore that may include data from various individual clients 101. In anexample, the common data store may include data from two clients 101.Further, the data from each client 101 may have two segments of data.The first segment of data 2504 may include data that may be utilized bya data mining facility 2502 for conducting various types of analyses.The second segment of data 2508 may include private or confidentialdata. The data mining facility 2502 may obtain the data from the firstsegment 2504 of both the clients' data for applying various data miningtechniques. The analytic module 134 may be coupled to the web hostingplatform 100 through an API that may be provided for accessing data fromthe common data store 106 related to various client attributes, whichmay be utilized in performing statistical analysis for understandingclient behavior. The results may be analyzed to create client retentionstrategies.

Referring now to FIG. 26, which illustrates a system for obtaining datafrom various clients 101. In an example, the system may include threedifferent clients: client 1, client 2, and client 3. Further, the datafrom these three clients 101 may include both private or confidentialdata and the data to be utilized for data mining. A data separationfacility 2602 may separate out the private data and the data to beutilized for data mining from all clients 101. A data mining facility2502 coupled to the data separation facility 2602 may obtain the datathat is to be utilized for data mining from the data separation facility2602 to conduct various types of analyses.

The data mining techniques may include, without limitations,classification, regression, association rule learning, and clustering.Classification is a data mining technique used to predict groupmembership for data instances. The common algorithms for classificationinclude decision tree learning, nearest neighbor, naive Bayesianclassification, and neural networks. Regression is a data miningtechnique used to fit an equation to a data set. Association rulelearning searches for relationships between variables. For example, asupermarket might gather data on client purchasing habits. Usingassociation rule learning, the supermarket can find out the productsfrequently bought together and use this information for marketingpurposes. Data clustering involves dividing data into groups of similarobjects.

The analytics facility 134 may apply predictive analysis for theapplications including, but not limited to, analytical ClientRelationship Management (CRM), direct marketing, cross-selling,collection analysis, portfolio, product, or economy level prediction,and fraud detection. Analytical CRM is a part of CRM that aims atstoring, analyzing, and applying the knowledge about clients and ways toapproach clients by typically using databases, statistical tools, datamining, machine learning, business intelligence, and reportingmethodologies. Direct marketing is a form of advertising that may reachand communicate with its audience directly without using the traditionalforms of advertising through mediums such as television, newspapers, orradio. The advertiser communicates straight with the target audiencethrough fliers, catalogue distribution, promotional letters, and streetadvertising. Cross-selling is a strategy of pushing new products tocurrent clients based on their past purchases. This strategy is designedto widen the client's reliance on the company and increase thelikelihood of client retention. Collection analysis includes analysis ofthe collection from a source and compares it with collections from othersources.

The analytics facility 134 may apply different models of predictiveanalysis including, but not limited to, predictive model, descriptivemodel, and decision model. The predictive model may use the past datafor predicting future events. It may be implemented to increase themarket efficiency. The descriptive model quantifies relationships indata and may be used to categorize clients 101 by their productpreferences. The descriptive model may also be utilized in simulating alarge number of individualized agents 118 for making predictions. Thismodel may use the existing data for making a decision.

FIG. 27 illustrates a schematic block diagram of a common servicearchitecture 100 that may support a website hosting service which usesan analytics module 134 to provide a client survival analysis. Survivalanalysis for a subscription business may be based on an application ofstatistical models. Survival is generally represented as a mathematicalcurve starting at 100%, or some specific value, and declining over time,such as a number of subscription days, months, or years on the new webhosting platform. The large populate of clients that use a web hostingplatform, such as the web hosting platform 100 described herein, mayfacilitate building survival analysis applications based on how longclients remain subscribed to the platform, such as to examine how longclients survive and to seek causes for why clients do or do not survive.As the cost of acquiring new clients can be very high, survival ofclients has a very high impact on the economic performance of a webhosting business. Longer surviving clients mean longer-term billing,without incurrence of new client acquisition costs. After a completedsurvival analysis, an agent 118 may view stacked indexes of survivalcharacteristics based on survival rates for a variety of clientparameters, such as client origin, client demographics, client type,client location, subscription type, price, service offering, quality ofservice, presence or absence of specific problems, extent ofcommunication with clients, client size, client referral, and many otherfactors that can be observed about a collection of clients,subscriptions, offerings, the like.

FIG. 27 includes portions of the common service architecture 100 toexemplify how data from a variety of sources can be analyzed to producevarious survival analyses that may be based on one or more types ofsurvival models. At the center of the embodiment of FIG. 27 is theanalytics module 134 that is further described elsewhere herein. Theanalytics module 134 may receive input from the operational supportsystem (OSS) 114 and third-party data 2718 of the common servicearchitecture 100. The data made available to the analytics module 134may be based on data that is available to the OSS 114, such as data fromthe common data store 106, data related to or provided by clients 101,and platform and/or client related data that is processed, updated, orotherwise accessible to agents 118. The analytics module 134 may applyone or more survival data models as described herein and represented byway of example in FIG. 27 as survival data model 2712 to data receivedfrom the OSS 114 and elsewhere to produce survival analyses depictedvariously as 2704, 2708, 2710, and 2714. Further details of the methodsof survival analysis as depicted in FIG. 27 are now presented.

Data retained in the common data store 106 may contain clientinformation related to a website hosting account or agreement,information about subscribers, information about types of hostedaccounts, information about types of subscriptions, information aboutpricing, information about past client behavior, information aboutcompetitors, and the like. The OSS 114 may retrieve data from the commondata store 106 or third party source that can be used to perform asurvival analysis. Relevant data may be data related to a particularclient, a particular type of client, a particular geographic location,and many other factors as noted herein or as would be understood by oneof ordinary skill in the art. The analytics module 134 may analyze thedata retrieved by the OSS 114 to populate a client survival data model,produce client survival graphical representations, perform predictiveanalysis of future survival, store survival analysis results in thecommon data store, and the like.

In the example of FIG. 27, the client data stored in the common datastore 106 that may be retrieved by the OSS 114 is represented by 2702A,2702B, 2702C, and 2702D, representing data for various clients, previoussurvival analysis results, control information related to the survivaldata model, and the like. As an example, and not a limitation, the dataelements depicted within the common data store 106 maybe for a singleclient and may include client data 2702A that may contain identifyinginformation provided by the client during registration such as name,address, telephone number, and the like. Similarly, client data 2702Bmay contain demographics information such as client size, type ofbusiness, public or private status, and the like. Further, client data2702C may contain geographic information such as client's locations,origin, and the like. Finally, in the example of FIG. 27, client data2702D may contain website hosting information such as the types ofservices subscribed to, the length of contract, contract modifications,and the like. Alternatively, 2702A may represent data for a firstclient, 2702B may represent data for a second client, 2702C mayrepresent business operations related data, 2702D may representsummarized data for former web hosting client, and the like. Anycombination of data that may be stored in the common data store 106 canbe processed by the analytics module 134 to benefit survival analysis.Likewise, although four different data types are depicted in theembodiment of FIG. 27, a smaller number or a larger number of differentdata types may be used in the survival analysis operations.

In the example of FIG. 27, the analytics module 134 may be used toanalyze client data retrieved by the OSS 114 from the common data store106. The analytics module 134 may cause the OSS 114 to retrieve clientdata that is relevant to a particular analysis such as a survivalanalysis, a client retention analysis, product mapping analysis, and thelike. The analytics module 134 may process the client data, and maypopulate a survival data model 2712. The survival data model 2712 maythen be used to perform statistical analysis on the client data.Alternatively, the survival data model 2712 may be derived from survivalanalysis theory and applications in medical-related survival analysis,actuarial analysis, population survival analysis, and the like. Varioussurvival analysis techniques are described herein and elsewhere that maybe appropriately used to generate web hosting client survival analysis.

The analytics module 134 may use a survival data model 2712 populatedwith client data retrieved by the OSS 114 from the common data store 106to generate statistical survival information. The statistical survivalinformation may be graphically represented as survival over time.Further in the example of FIG. 27 the statistical survival informationis represented by 2704, 2708, 2710, and 2714. In the example, survivalregion graph 2704 is a graphical representation of client survival basedon client region. The analytics module 134 may analyze usage andsurvival patterns for one or more clients in a given region to create astatistical model of survival for a region or a model for comparingsurvival rates among different regions. The analysis may be targeted ata particular aspect or feature of the web hosting service and may allowthe web hosting provider to better tailor web hosting service offeringsto differing geographic locations, with a goal of maximizing theeconomic benefit of hosting the client by optimizing net profit expectedto be received from a population of clients over a predicted period ofsurvival time. Survival size graph 2708 is a graphical representation ofclient survival based on client size. The analytics module 134 mayanalyze usage and survival patterns for one or more clients of a givensize to create a statistical model of survival related to the size of aclient. The analysis may be targeted at a particular aspect or featureof the web hosting service and may allow the web hosting provider tobetter tailor web hosting service offerings to clients of differingsize. The predicted survival graph 2710 is a graphical representation ofa predicted client survival based on factors of similarity to a priorclient. The analytics module 134 may be able to predict the survivalrate for a client that is similar to one or more prior clients. Byanalyzing the data for the prior client(s) and/or for a new or currentclient, the analytics module 134 may be able to correlate causes thatmay be applicable to a prediction of survival for the new or existingclient, thereby suggesting changes that may result in longer, or moreprofitable, survival periods for particular clients or groups ofclients.

Survival analysis may also be performed based on multiple overlaysincluding web hosting system data (e.g. client data) and third-partydata. In an example, an overlay that includes a mix of subscriptionterms (e.g. 1 year plan versus 3 year plan) and external data (e.g.macroeconomic data) may facilitate survival outcome analysis. Factorssuch as employment conditions, interest rate, stock market, and the likethat impact portions of the population in general may impact web hostingclients. This data fusion of web hosting and third party data may enablepredictable and reliable analysis that allows a web hosting serviceprovider to offer services that are balanced with the externalmacroeconomic environment.

FIG. 28 illustrates a schematic block diagram of a common servicearchitecture 100 that may support a website hosting service which usesan analytics module 134 to provide a mapping analysis of one or moreproducts, website hosting offerings, service packages, market-specificofferings, and the like. By relationally mapping both dependent andindependent products/services/offerings the product mapping analysis maycreate a product map that may be depicted as a visual representation ormatrix of product/service/offering similarity. The product map ofsimilarity may then be used to create a product bundling, a marketingstrategy, an advertising concept, a website hosting offering, a servicepackage, a market-specific offering, and the like. The product map ofsimilarity may be presented on a three-dimensional (3D)product/service/offering similarity map or as a 2D matrix of values ofsimilarity. The 3D similarity map may provide a visual element for eachproduct/service/offering covered by the mapping analysis. The 3Dsimilarity map may also provide a visual element depicting thesimilarity among products/services/offerings. As an example, and not alimitation, two products may be connected by an arrow or a line; spaceof predetermined distance between products may indicate a degree ofsimilarity; relative size of product/service/offering elements mayindicate the degree of similarity, and the like.

FIG. 28 includes portions of the common service architecture 100 toexemplify how data from a variety of clients may be analyzed to producevarious product mappings that may be based on one or more types of usagedata models. At the center of the embodiment of FIG. 28 is the analyticsmodule 134 that is further described elsewhere herein. The analyticsmodule 134 may receive input from the operational support system (OSS)114 of the common service architecture 100, a third-party data source2718, or other sources of data associated with the common servicearchitecture 100. The data that is made available to the analyticsmodule 134 may be based on data available from the third-party datasource 2718 and/or data accessible by the OSS 114 such as data from thecommon data store 106, data related to or provided by clients 101, andplatform and/or client related data that is processed, updated, orotherwise accessible to agents 118, and other platform relatedinformation including without limitation, existing websiteproducts/services/offerings, sales data related thereto; newproducts/services/offerings not yet offered to clients of the commonservice architecture 100, products/services/offerings currently offeredby a third-party website hosting service (e.g. an acquisition targetthird-party service), features, benefits, costs, subscription bundlingrules, other business rules, sales forecasts, target client information,and the like. The analytics module 134 may apply one or more usage datamodels as described herein and exemplarily represented in FIG. 28 asusage data model 2802 to data received from the OSS 114 and elsewhere toproduce a product/service/offering map consisting ofproducts/services/offerings depicted variously as 2804, 2808, 2810,2812, and 28214. Further details of the methods of product mappinganalysis as depicted in FIG. 28 are now presented.

Data retained in the common data store 106 may contain clientinformation related to a website hosting account or agreement,information about competitors, and the like. The OSS 114 may retrievedata from the common data store 106, or any of the other data sourcesdescribed herein to be used to perform a mapping analysis of one or moreproducts, website hosting offerings, service packages, market-specificofferings, and the like. Relevant data may be data related to aparticular client, a particular type of client, a particular geographiclocation, a product/service/offering, and the like. The analytics module134 may analyze the data retrieved by the OSS 114 to populate a usagedata model, produce similarity mapping graphical representations,perform predictive analysis of possible product groupings, store productmapping results in the common data store 106, and the like. Thesimilarity mapping 3D representation may support predictive analysis byallowing a user to manipulate the presented elements, causing theanalysis to predict required changes in parameters that contribute tothe similarity mapping. In an example, by allowing a user to moveelement 2808 half the distance toward element 2804, a geographic salesparameter may be increased by fifty percent, indicating that if sales ina geographic region were to increase by fifty percent the similaritybetween the 2808 and 2804 elements would be cut in half. The similaritymapping 3D representation may also allow a user to select a dimension ofsimilarity using drop down selector 2818. By selecting a parameter, suchas a primary product/service/offering, new product sales revenue,customer size, and the like, the 3D similarity map may adjust to reflectthe selected dimension of similarity. Dimensions of similarity mayinclude any of the data types, sources, desired business outcomes,business actions, and the like that may be appropriate for successfullyoperating a website hosting platform.

In the example of FIG. 28, the client data stored in the common datastore 106 that may be retrieved by the OSS 114 is represented by 2702A,2702B, 2702C, and 2702D, representing data for various clients, previoussimilarity mapping analysis results, and the like. As an example, andnot a limitation, the data elements depicted within the common datastore 106 that are retrieved by the OSS 114 for presenting to theanalytics facility 134 may include usage information for a plurality ofclients who have purchased a particular product offered by the webhosting service 100. Further in the example, data 2702A may contain alist of products used by a client. 2702B may contain a list of productsused by another client, with 2702C and 2702D containing usage data fortwo additional clients. Alternatively, the data elements depicted withincommon data store 106 may be for a plurality of products that arethought to be related. Further in the example, data 2702A may contain alist of all clients to have purchased a particular product. 2702B maycontain a list of all clients that have purchased a different product,with 2702C and 2702D containing lists of clients who have purchasedother products. Similarity among clients purchasing various offeringsmay suggest what offerings to push to clients who, based on suchsimilarity, might favor a particular offering. Any combination of datathat may be stored in the common data store 106 can be processed by theanalytics module 134 to benefit survival analysis. Likewise, althoughfour different data types are depicted in the embodiment of FIG. 28, asmaller number or a larger number of different data types may be used inthe product mapping/analysis operations.

In the example of FIG. 28, the analytics module 134 may be used toanalyze data retrieved by the OSS 114 from the common data store 106 forproduct/service/offering similarity mapping. The analytics module 134may cause the OSS 114 to retrieve data that is relevant to a similaritymapping analysis as described herein. The analytics module 134 may thenpopulate a 3D product/service/offering map with the results of itsanalysis.

The 3D product/service/offering map may facilitate graphicallyrepresenting various degrees of similarity among differentproducts/services/offerings. The analytics module 134 may use a visualelement to represent a product/service/offering being mapped. In FIG.28, elements 2804, 2808, 2810, 2812, and 2814 may represent variousproducts/services/offerings in a 3D similarity map. The analytics module134 may use a connecting element such as an arrow, a line, a distance,or any other visual distinction of elements in the similarity map torepresent one or more dimensions of similarity. When the similarity isrepresented by a connecting element, the size, shape, width, length,appearance, or other visual distinction may indicate a degree ofsimilarity. As an example, a shorter connecting element may represent acloser relationship between two products than a longer connectingelement. When the similarity is represented by a distance betweenelements, the distance in at least two or more dimensions may indicate adegree of similarity. To facilitate visually depicting a plurality ofdimensions of similarity, a combination of similarity depicting elementsmay be used. In the example of FIG. 28, at least three dimensions may bepresented by similarity elements including: size of theproduct/service/offering element, distance of product/service/offeringelements, and a similarity connecting arrow. As depicted in FIG. 28, theanalytics module 134 may adjust the size of the product/service/offeringelements to graphically represent one or more dimensions of similarityamong different products. As an example, product elements that arevisually similar in size may represent a closer degree of similaritythan product elements that are dissimilar in size.

The analytics module 134 may alternatively generate a product similaritymatrix that produces values in a table of products for comparison. Inthe example of FIG. 28A, the aforementioned analytics module 134 andusage model 2802, and the like are used to generate a two or threedimensional matrix 2820 that includes a list of products across the axesof the matrix and a dimension of similarity selector that facilitateslooking at product/service/offering similarity for a variety ofdimensions. In a three-dimensional embodiment, a data cube may beenvisioned to include multi-product similarity values or may includesimilarity values for any two products for a variety of similaritydimensions.

FIG. 29 illustrates a schematic block diagram of a common servicearchitecture 100 that may support a website hosting service which usesan analytics module 134 to provide a client retention analysis. Byanalyzing factors that cause a client to be retained as well as factorsthat cause a client to be lost and the intersection between thesefactors, the analytics module 134 may create a client factor list whichmay be used in developing and/or executing a strategy for clientretention. The factor list may contain factors relevant to clientretention. The retention analysis may facilitate determining a predictedeffectiveness of a particular client retention strategy that is beingexecuted by identifying changes in the list of factors, the degree towhich a factor contributes to client retention, and the like. The listof factors may include factors that may cause client not to be retained.This list may include weights or priorities for at least some of thefactors that may be based on certain client retention goals, businessrevenue goals, and the like.

FIG. 29 includes portions of the common service architecture 100 toexemplify how data from a variety of clients may be analyzed to producevarious client retention analyses that may be based on one or more typesof usage/retention data models. At the center of the embodiment of FIG.29 is the analytics module 134 that is further described elsewhereherein. The analytics module 134 may receive input from the operationalsupport system (OSS) 114 and third-party data 2718 of the common servicearchitecture 100. The data that is made available to the analyticsmodule 134 may be based on data available to the third-party data 2718and the OSS 114 such as data from the common data store 106, datarelated to or provided by clients 101, and platform and/or clientrelated data that is processed, updated, or otherwise accessible toagents 118, and other website hosting service related information. Theanalytics module 134 may apply one or more usage data models asdescribed herein and represented in FIG. 29 as usage/retention datamodel 2902 to data received from the OSS 114 and elsewhere to produce aclient retention results which may include one or more pools of clientfactors depicted as 2904, 2908, 2910, and 2912. Further details of themethods of retention analysis as depicted in FIG. 29 are now presented.

Data retained in the common data store 106 that may be used in clientretention or hazard analysis may contain client information related to awebsite hosting, information about competitors, third-party data, andthe like. The OSS 114 may retrieve data from the common data store 106that can be used to perform a hazard/retention analysis. Relevant datamay be data related to a particular client, a particular type of client,a particular geographic location, and the like. The analytics module 134may analyze the data retrieved by the OSS 114 to populate ausage/retention data model, produce a client retention representation,perform predictive analysis of possible retention strategies, and thelike. Any combination of data that may be stored in the common datastore 106 can be processed by the analytics module 134 to benefit clientretention analysis. Likewise, although four different data types aredepicted in the embodiment of FIG. 29, a smaller number or a largernumber of different data types may be used in the productmapping/analysis operations.

Client survival analysis as described herein and in particular withrespect to FIG. 27 may be combined with the present hazard/retentionanalysis to improve analysis results. In an example, client survivalanalysis may produce a list of clients who have not survived and mayidentify various factors related thereto. This information may befurther analyzed by a hazard/retention analysis to identify potentialhazards to client retention that may be applied to a business processfor improving client retentions, reducing client retention hazards, andimpacting overall client survival. Changes made as a result of ahazard/retention analysis may be found by comparing survival analysisbefore the changes to survival analysis performed after the changes.

In the example of FIG. 29, the client data stored in the common datastore 106 that may be retrieved by the OSS 114 is represented by 2702A,2702B, 2702C, and 2702D, representing data for various clients, previousretention analysis results, and the like. As an example, and not alimitation, the data elements depicted within the common data store 106may be for a plurality of clients from a certain geographic region, whohave terminated a particular product offering at similar times, who haveretained a particular product offering for a specified period of time,and the like. Further in the example, data 2702A may contain factorsassociated with a client. 2702B may contain factors associated withanother client, with 2702C and 2702D containing factors for twoadditional clients. Representative data elements 2702A through 2702D mayalternatively represent data sets of prior hazard/retention analysisoutput, client retention hazard factors from third-party data sources,and the like.

In the example of FIG. 29, the analytics module 134 may be used toanalyze data retrieved by the OSS 114 from the common data store 106 foruse with the hazard/retention data model 2902. The analytics module 134may cause the OSS 114 to retrieve client data that is relevant to aretention analysis. The analytics module 134 may then populate a clientretention model 2902, perform retention and/or hazard analysis, producea graphical presentation of the results of its analysis, store theresults in the common data store, forward the results to a third partyor another facility of the common service architecture 100 (e.g.business operations 140), and the like. The retention graphical resultsmay, for example visually represent the retention factors associatedwith client retention. The analytics module 134 may use a visual factorselement to represent factors associated with a retained client or a lostclient. In FIG. 29, 2904, 2908, 2910, and 2912 represent such retentionfactor elements.

A retained client may have a common retention factor with a lost client.As an example, in FIG. 29 one or more retention factors depicted in theretained client factor output 2904 may represent factors associated witha retained client. Similarly, one or more retention-related factors inthe lost client factor output 2908 may represent factors associated witha lost client. The intersection of such factors (those factors that aretained client and a lost client have in common) may be represented by2910. Retention factor output 2912 may represent factors that influenceor reflect client retention hazards. Retention factor output 2912 mayinclude those factors from lost clients that are not also present inretained clients (e.g. output 2908 exclusive of output 2910), factorsthat are common to retained and lost clients (output 2910), all factorsrelated to lost clients (output 2908), and the like.

Client hazard/retention analysis may address all client-retentionrelated criteria, or it may be focused on factor elements based on asubset of all possible factors, such as for a group of clients fittingpredetermined criteria. In this way, hazard/retention analysis mayprovide information that may be used to facilitate attempting to retaina particular type of client (e.g. a small business client, a non-profitclient, a client who has been a subscriber for more than a minimumnumber of years, a client who has contacted customer service more than aminimum number of times or more frequently than a minimum rate or thelike).

FIG. 30 illustrates a schematic block diagram of a common servicearchitecture 100 that may support a website hosting service which usesan analytics module 134 to provide a client financial impact analysis.By analyzing factors that cause a client to perform well financially aswell as factors that cause a client to perform poorly financially andthe intersection between the two sets of factors, the analytics module134 may create a client factor list which may be used in developingand/or executing a strategy for improving client financial results forthe service. The factor list may contain factors relevant to clientfinancial performance. The client financial impact analysis mayfacilitate determining predicted effectiveness of a particular clientfinancial performance strategy that is being executed by identifyingchanges in the list of factors, the degree to which a factor contributesto client financial impact, and the like. The list of factors mayinclude factors that may cause client not to produce favorable financialresults. This list may include weights or priorities for at least someof the factors that may be based on certain client financial performancegoals, business revenue goals, and the like.

FIG. 30 includes portions of the common service architecture 100 toexemplify how data from a variety of clients may be analyzed to producevarious client financial analyses that may be based on one or more typesof usage/financial data models. At the center of the embodiment of FIG.30 is the analytics module 134 that is further described elsewhereherein. The analytics module 134 may receive input from the operationalsupport system (OSS) 114 and third-party data 2718 of the common servicearchitecture 100. The data that is made available to the analyticsmodule 134 may be based on data available to the third-party data 2718and the OSS 114 such as data from the common data store 106, datarelated to or provided by clients 101, and platform and/or clientrelated data that is processed, updated, or otherwise accessible toagents 118, and other website hosting service related information. Theanalytics module 134 may apply one or more usage data models asdescribed herein and represented in FIG. 30 as usage/financial datamodel 3002 to data received from the OSS 114 and elsewhere to produce aclient financial impact results that may include a graphicalpresentation which contains lists of factors related to client financialimpact depicted as 3004, 3008, 3010, and 3012. Further details of themethods of retention analysis as depicted in FIG. 30 are now presented.

The method of client financial results assessment may include receivingwebsite hosting client usage data for a plurality of website hostingservices. Data retained in the common data store 106 may contain clientdata and information related to a website hosting, information aboutcompetitors, and the like. The OSS 114 may retrieve data from the commondata store 106 that can be used to perform a financial impact analysis.Relevant data may be data related to a particular client, a particulartype of client, a particular geographic location, and the like. Theanalytics module 134 may analyze the data retrieved by the OSS 114 topopulate a usage/financial data model, produce a client financial impactrepresentation, perform predictive analysis of possible maximizingfinancial benefits strategies, and the like. Any combination of datathat may be stored in the common data store 106 can be processed by theanalytics module 134 to benefit client financial performance and/orfinancial impact analysis. Likewise, although four different data typesare depicted in the embodiment of FIG. 30, a smaller number or a largernumber of different data types may be used in the productmapping/analysis operations.

Client survival and retention analyses as described herein and inparticular with respect to FIGS. 27 and 29, may be combined with thepresent client financial impact analysis to improve analysis results. Inan example, client survival analysis may produce a list of clients whohave not survived and may identify various factors, including financialfactors, related thereto. Client hazard/retention analysis may produceresults that relate to financial factors that present hazards toretaining clients. These survival analysis and/or retention analysisresults may be further included in a client financial impact analysis toidentify potential financial reasons for client survival results and/orfinancial hazards to client retention that may be applied to a businessprocess for improving client financial performance, reducing clientfinancial performance degradation, and impacting overall clientsurvival. Changes made as a result of a financial impact analysis may befound by comparing survival analysis before the changes to survivalanalysis performed after the changes. Likewise, retention hazardanalysis performed after changes made to improve financial impact mayreflect the impact of those changes on financial factors impactingclient retention.

In the example of FIG. 30, the client data stored in the common datastore 106 that may be retrieved by the OSS 114 is represented by 2702A,2702B, 2702C, and 2702D, representing data for various clients, previousfinancial impact analysis results, and the like. As an example, and nota limitation, the data elements depicted within the common data store106 may be for a plurality of clients from a certain geographic region,who have achieved favorable financial results from using the web hostingservice, who have not achieved favorable financial results from usingthe web hosting service, and the like. Further in the example, data2702A may contain factors associated with a client. 2702B may containfactors associated with another client, with 2702C and 2702D containingfactors for two additional clients. Representative data elements 2702Athrough 2702D may alternatively represent data sets of prior clientfinancial impact analysis output, client financial impact factors fromthird-party data sources, and the like.

In the example of FIG. 30, the analytics module 134 may be used toanalyze client data retrieved by the OSS 114 from the common data store106 for use with the financial impact data model 3002. The analyticsmodule 134 may cause the OSS 114 to retrieve client data that isrelevant to a financial impact analysis. The analytics module 134 maythen populate a client financial impact model 3002, perform financialimpact analysis, produce a graphical presentation of the results of itsanalysis, store the results in the common data store, forward theresults to a third party or another facility of the common servicearchitecture 100 (e.g. business operations 140), and the like. Thefinancial impact graphical results may, for example visually representthe financial impact factors associated with client financial impact.The analytics module 134 may use a visual factors element to representfactors associated with a client who produces favorable financialresults or clients who do not. In FIG. 30, 3004, 3008, 3010, and 3012represent such financial impact factor analysis results elements.

The financial impact graphical results may visually represent thefactors associated with the financial impact on clients. The analyticsmodule 134 may use a visual factors element to represent factorsassociated with a financially benefitted client or a client that did notderive a financial benefit from the web hosting service. In FIG. 30,3004, 3008, 3010, and 3012 represent such factors elements.

A financially benefitted client may have a common client factor with aclient that was not benefitted. As an example, in FIG. 30 the factorelement 3004 may represent factors associated with a financiallybenefitted client. Similarly, 3008 may represent factors associated witha client that was not benefitted financially. The intersection offactors (those factors that a financially benefitted client and a clientthat was not financially benefitted have in common) may be representedby 3010. Financial impact factor output 3012 may represent factors thatinfluence or reflect client financial impact. Financial impact factoroutput 3012 may include those factors from unfavorable financial resultsclients that are not also present in favorable financial impact clients(e.g. output 3008 exclusive of output 3010), factors that are common tofavorable and unfavorable clients (output 3010), all factors related tounfavorable clients (output 3008), and the like.

Client financial impact analysis may address all client-financial impactrelated criteria, or it may be focused on factors based on a subset ofall possible factors, such as for a group of clients fittingpredetermined criteria. In this way, financial impact analysis mayprovide information that may be used to facilitate attempting to improvea financial impact of a particular type of client (e.g. a small businessclient, a non-profit client, a client who has been a subscriber for morethan a minimum number of years, a client who has contacted customerservice more than a minimum number of times or more frequently than aminimum rate or the like, a client who has recently reduced subscriptionservices).

FIG. 31 illustrates a schematic block diagram of a common servicearchitecture 100 that may support a website hosting service which usesan analytics module 134 to facilitate product selection, such as via aclient purchasing profile. By analyzing a plurality of client's productpurchasing activity, the analytics module 134 may create a clientproduct probability grid. The client product probability grid maycontain probabilities that a given client will purchase a given productand may be used to facilitate identifying a subset of products that ahave a favorable probably of client purchase. A random forest algorithmor similar algorithm may be applied to at least determine theprobabilities that a given client will purchase a given product.

FIG. 31 includes portions of the common service architecture 100 toexemplify how data from a variety of clients may be analyzed to producevarious client financial analyses that may be based on one or more typesof usage data models. At the center of the embodiment of FIG. 31 is theanalytics module 134 that is further described elsewhere herein. Theanalytics module 134 may receive input from the operational supportsystem (OSS) 114 of the common service architecture 100. The data thatis made available to the analytics module 134 may be based on dataavailable to the OSS 114 such as data from the common data store 106,data related to or provided by clients 101, and platform and/or clientrelated data that is processed, updated, or otherwise accessible toagents 118, and other website hosting service related information.

In FIG. 31, the products offered by the web hosting service arerepresented by 3102, 3104, 3108, and 3110. The clients are representedby 3112, 3114, 3118, and 3120. A grid that may be formed when theclients are used as rows and products as columns may include a productpurchase grid 3106. The analytics module 134 may create the productpurchase grid 3106 from usage data 3124 and web offering data 3126 thatmay be received from the OSS 114. The analytics module 134 may alsoapply one or more usage data models as described herein and representedin FIG. 31 as random forest data algorithm 3122 to the product purchasegrid 3106 to produce a client product purchase probability grid 3116.Alternatively, the product purchase probability grid 3116 data may bestored in a separate logical layer in the product purchase grid 3106.The client product purchase probability grid 3116 may containprobabilities that a given client will purchase a given product. Furtherdetails of the methods of retention analysis as depicted in FIG. 31 arenow presented.

Data retained in the common data store 106 may contain clientinformation related to a website hosting, information about competitors,third-party data, and the like. The OSS 114 may retrieve data from thecommon data store 106 that can be used to perform a client purchasinganalysis. Relevant data may be data related to a particular client, aparticular type of client, a particular geographic location, and thelike. The analytics module 134 may analyze the data retrieved by the OSS114 and elsewhere to populate a product purchase grid 3106, a clientproduct probability grid 3116, and the like to facilitate performingpredictive analysis of possible marketing and sales strategies usingbundling of services, offering one or more services to one or morecustomers, improve utilization of marketing and sales resources, targetoffers to clients, adjust current offering practices to existingclients, and the like. Any combination of data that may be stored in thecommon data store 106 can be processed by the analytics module 134 tobenefit product purchase probability analysis. Likewise, although fourdifferent data types are depicted in the embodiment of FIG. 30, asmaller number or a larger number of different data types may be used inthe product purchase probability analysis operations

In the example of FIG. 31, the analytics module 134 may be used toanalyze client data, website hosting product/service/offering data,purchase probability model data, and other data relevant to purchaseprobability analysis that may retrieved by the OSS 114 from the commondata store 106. The analytics module 134 may cause the OSS 114 toretrieve client data that is relevant to a client's purchasing history.The analytics module 134 may then populate a client product purchasingpredictability grid 3116 that may be depicted in a graphicalpresentation of the analysis results.

In the example of FIG. 31, the analytics module 134 may process theclient data, and may populate a random forest data model 3122. Therandom forest data model 3122 may then be used to perform statisticalanalysis on the client purchasing data. The random forest data model mayallow the analytics module 134 to populate the client productprobability grid 3116 with the probability of a client purchasing aparticular product.

Once populated, the product purchase probability grid 3116 may be used,along with other criteria to identify entries in the grid 3116 thatrepresent favorable probabilities of purchase. In the example of FIG.31, favorable entries 3128 may include probabilities of purchase PC forclient 3114 with product/offer 3104, and purchase probability PH forclient 3118 with product/offer 3108. As described elsewhere herein, theproduct/client combinations represented by 3128 may indicate a greaterlikelihood that the client will purchase the product. Such informationmay significantly benefit a marketing and/or sales program by helpingidentify sales opportunities.

Now referring to FIG. 32 which depicts an operational flow for analyzingclient and product purchasing data to produce a purchase probabilityoutput, the operational flow, which may be executed as an algorithm in acomputer program, includes a few steps for processing data that has beencaptured or provided. The flow starts at step 3130 and proceeds to step3132 during which a grid of items purchased and items not purchased bycustomers is produced. After at least a portion of the grid of step 3132is produced, step 3134 may commence to apply a random forest algorithmto facilitate determining probabilities of clients purchasing products.The grid created in step 3132 may be further populated with the purchaseprobabilities calculated in step 3134, such as by adding a purchaseprobability data layer to the grid. Alternatively a new grid may becreated using similar dimensions (e.g. clients along one axis andproducts along the other). When at least a portion of the purchaseprobabilities are calculated in step 3134, step 3138 may commence inwhich a subset of client/offering combinations may be identified basedon the probabilities calculated in step 3134 representing favorableprobabilities of purchase of the product/offering by the client. Otherfactors, such as a sales goal, a product road map, a product phase-outplan, a client retention objective, a per-client revenue goal, clientservice upgrade goal, and any other type of criteria related tosuccessfully operating a website hosting service may be used todetermine which of the purchase probabilities represent favorableprobabilities of purchase. The flow may complete when one or morefavorable purchase probability entries are identified. Alternatively,the flow may complete once all of the favorable purchase probabilityentries are identified. The flow terminates at step 3140. Although thesteps in the operational flow of FIG. 32 are shown in a logicalsequence, steps can be executed in parallel so long as a minimum amountof information that is required by a subsequent step is available tothat step; ex: 3134 may commence without completing step 3132 so long assome grid elements are populated.

Further, FIG. 33 depicts a flowchart illustrating an operational flowfor predicting which of a plurality of clients is likely to purchase aproduct or service. The operational flow may be executed as an algorithmin a computer program that includes a few steps for processing data thathas been captured or provided. The flow starts at step 3302 and proceedsto step 3304 during which information about a subset of clients may betaken. The clients may have bought a product or service, such as a webdomain hosting service or service package as variously described herein.After the information is taken at step 3304, during step 3308 aprocessor may use that information to derive scores and oddsprobabilities of any particular client buying any of a wide range ofproducts/services. At step 3310, a profile may be developed frominformation available to the new website hosting architecture platform,the profile may be characteristic of a client who may have bought theproduct or service. Step 3312 may commence by applying a random forestalgorithm or any other similar algorithm to the client and product datagenerated in and/or used to generate the elements in steps 3308 and 3310to facilitate predicting which clients or potential would likely buy theproducts. The prediction may be used to determine which action(s) shouldbe taken regarding the product(s) and client(s) that may financially orotherwise benefit the platform, such as offering the product(s) to theclients(s). The flow terminates at step 3314. Although the steps in theoperational flow of FIG. 33 are shown in a logical sequence, steps canbe executed in parallel so long as a minimum amount of information thatis required by a subsequent step is available to that step.

Migration of web hosting services from one architecture to another, suchas where at least one of the architectures is a service poolarchitecture that may be configured to support multiple boxes percustomer, may be associated with a website hosting service that is basedon a common service architecture and third party services. An automatedtool for facilitating migration may include migration of third-partyservices. Prior to or during migration, the automated tool may determinethat certain services available from a first website hostingarchitecture may be candidates for third-party services in a secondwebsite hosting architecture. In an example the first architecture maycomprise a server architecture that serves a plurality of servicesdedicated exclusively to a specific website that may serve the servicesnecessary for the specific website from one or more machines. To ensurethat all services are migrated to a second web hosting architecture thatmay comprise a server architecture that serves a plurality of commonservices to a plurality of unrelated and/or unaffiliated websites fromone or more machines, the tool may determine that at least one of theplurality of services may be available to clients of the second webhosting architecture through a third party[interface/API/plug-in/service] that allows the clients to experienceinformation consistent with a market specific service offering.

By identifying services to be migrated that are available as third-partyservices, the tool may allow a web hosting service to migrate andincorporate services that are native to the first web hostingarchitecture as well as third party services that are provided throughthe first web hosting architecture. In addition to identifying servicesin the first architecture that may be provided as third-party servicesin the second architecture, migration may result in third-party servicesprovided through the first architecture to be migrated to services thatare natively provided by the second architecture. This may provide amore highly integrated and smoother running web hosting experience forthe clients who are migrated from the first architecture to the secondarchitecture.

Migration of web hosting services from one architecture to another, suchas where at least one of the architectures is a service poolarchitecture that may be configured to support multiple boxes percustomer, may be associated with a website hosting service that is basedon a common services web hosting architecture that supports multiplebranding and OSS consistency. An automated tool for facilitatingmigration may include migration of branding and operational supportservices. Prior to or during migration, the automated tool may determinethat certain branding capabilities or operational support servicesavailable from a first website hosting architecture may be candidatesfor integrating with multiple branding and operational support servicecapabilities of a second website hosting architecture. In an example,the first architecture may comprise a server architecture that serves aplurality of services dedicated exclusively to a specific website thatserves the services necessary for the specific website from one or moremachines. To ensure that all services are migrated to a second webhosting architecture that may comprise a server architecture that servesa plurality of common services to a plurality of[unrelated/unaffiliated] websites from one or more machines, the toolmay determine that a brand of the first web hosting architecture may besuitable for being made available to clients and prospective clients ofthe second web hosting architecture through the multiple brandingcapability. The brand of the first web hosting architecture may beconfigured as a market specific offering of the second web hostingarchitecture wherein the offering may be maintained under a consistentlook and feel associated with the market specific offering whenpresenting account service user interfaces. Such offerings may includedifferent brands, messages, service terms and/or different pricingstructures.

Migration of web hosting services from one architecture to another, suchas where at least one of the architectures is a service poolarchitecture that may be configured to support multiple boxes percustomer, may be associated with a website hosting service that is basedon a an unaffiliated web domain common hosting service architecture withone or more service representative plug ins. An automated tool forfacilitating migration may include migration of web hostingmarket-specific information to the common hosting service architectureso that it is accessible through one or more service representative plugins. In an example, the first architecture may comprise a serverarchitecture that serves a plurality of services dedicated exclusivelyto a specific website that serves the services necessary for thespecific website from one or more machines. To ensure successfulmigration from the first architecture to a second web hostingarchitecture that may comprise a server architecture that serves aplurality of common services to a plurality of [unrelated/unaffiliated]websites from one or more machines, the tool may determine that the lookand feel of the first architecture may be made marketed to clients andprospective clients of the second architecture through a plurality ofwebsites offering a different market specific offering. The secondarchitecture may provide service representatives that support aplurality of different market specific offerings and suchrepresentatives may be provided with information facilitating providingthe appropriate service for a particular market specific offering. Insuch a situation, service representatives of the second architecturewould receive information about the market-specific nature of the firstarchitecture to facilitate providing appropriate service to subscriptionclients of the first architecture in a market-specific way.

Migration of web hosting services from one architecture to another, suchas where at least one of the architectures is a service poolarchitecture that may be configured to support multiple boxes percustomer, may be associated with an unaffiliated website hosting servicethat is based on service pools with flexible resources. An automatedtool for facilitating migration may include migration of services from afirst architecture to appropriate service pools with flexible resourcesof a second architecture. Prior to or during migration, the automatedtool may determine that certain services available from a first websitehosting architecture may be candidates for integrating within one ormore service pools that may be adapted to provide flexible resources ina second website hosting architecture. In an example the firstarchitecture may comprise a server architecture that serves a pluralityof services dedicated exclusively to a specific website that may servethe services necessary for the specific website from one or moremachines. To ensure that all services are migrated to a second webhosting architecture that may comprise a server architecture that servesa plurality of common services to a plurality of[unrelated/unaffiliated] websites from one or more machines, the toolmay determine that at least one of the plurality of services of thefirst architecture may be made available to clients of the second webhosting architecture through one or more of the second architectureservice pools that themselves may be distributed across a plurality ofservers with each server adapted to provide an overlapping service setto facilitate flexible resources from each of the service pools. In someinstances, the servers may be virtualized, physical or a combination ofboth.

Migration of web hosting services from one architecture to another, suchas where a virtual network is used during migration, may be associatedwith a website hosting service that is based on a common servicearchitecture and third party services. An automated tool forfacilitating migration may include migration of third party services.Prior to or during migration, the automated tool may determine thatcertain services available from a first website hosting architecture maybe candidates for third-party services in a second website hostingarchitecture. In an example, a virtual network is used during migrationto facilitate keeping the network active during the movement of IPaddresses from one architecture to another. To ensure that all servicesare migrated to a second web hosting architecture, the tool mayestablish a virtual network between the first web hosting architectureand the second web hosting architecture that allows for direct access tothird-party services when a request for the candidate third-partyservices is made during migration. In addition, the tool may determinethat at least one of the plurality of services may be available toclients of the second web hosting architecture through a third party[interface/API/plug-in/service] that allows the clients to experienceinformation consistent with a market specific service offering.

By identifying services to be migrated that are available as third-partyservices, the tool may allow a web hosting service to use a virtualnetwork to migrate and incorporate services that are native to the firstweb hosting architecture as well as third party services that areprovided through the first web hosting architecture. In addition toidentifying services in the first architecture that may be provided asthird-party services in the second architecture, migration may result inthird-party services provided through the first architecture to bemigrated to services that are natively provided by the secondarchitecture. This may provide a more highly integrated and smootherrunning web hosting experience for the clients who are migrated from thefirst architecture to the second architecture.

Migration of web hosting services from one architecture to another, suchas where a virtual network is used during migration, may be associatedwith a website hosting service that is based on a common servicearchitecture that supports multiple branding and OSS consistency. Anautomated tool for facilitating migration may include migration ofbranding and operational support services. Prior to or during migration,the automated tool may determine that certain branding capabilities oroperational support services available from a first website hostingarchitecture may be candidates for integrating with multiple brandingand operational support service capabilities of a second website hostingarchitecture. In an example of using a virtual network during migrationto facilitate keeping the network active during the movement of IPaddresses from one architecture to another the automated tool may handlebranding migration. To ensure that all services are migrated to a secondweb hosting architecture, the tool may determine that a brand of thefirst web hosting architecture may be suitable for being made availableto clients and prospective clients of the second web hostingarchitecture through the multiple branding capability. The brand of thefirst web hosting architecture may be configured as a market specificoffering of the second web hosting architecture wherein the offering maybe maintained under a consistent look and feel associated with themarket specific offering when presenting account service userinterfaces. Such offerings may include different brands, messages,service terms and/or different pricing structures.

By identifying services to be migrated that are available as brandingand operational support services, the tool may allow a web hostingservice to use a virtual network to migrate and incorporate servicesthat are native to the first web hosting architecture as well as thirdparty services that are provided through the first web hostingarchitecture. In addition to identifying services in the firstarchitecture that may be provided as branding and operational supportservices in the second architecture, migration may result in brandingand operational support services provided through the first architectureto be migrated to services that are natively provided by the secondarchitecture. This may provide a more highly integrated and smootherrunning web hosting experience for the clients who are migrated from thefirst architecture to the second architecture.

Migration of web hosting services from one architecture to another, suchas where a virtual network is used during migration, may be associatedwith a website hosting service that is based on an unaffiliated webdomain common hosting service architecture with one or more servicerepresentative plug ins. An automated tool for facilitating migrationmay include migration of web hosting market-specific information to thecommon hosting service architecture so that it is accessible through oneor more service representative plug ins. In an example of using avirtual network during migration to facilitate keeping the networkactive during the movement of IP addresses from one architecture toanother, the tool may determine that the look and feel of the firstarchitecture may be made marketed to clients and prospective clients ofthe second architecture through a plurality of websites offering adifferent market specific offering. The second architecture may provideservice representatives that support a plurality of different marketspecific offerings and such representatives may be provided withinformation facilitating providing the appropriate service for aparticular market specific offering. In such a situation, servicerepresentatives of the second architecture would receive informationabout the market-specific nature of the first architecture to facilitateproviding appropriate service to subscription clients of the firstarchitecture in a market-specific way.

Migration of web hosting services from one architecture to another, suchas where a virtual network is used during migration, may be associatedwith an unaffiliated web domain hosting service that is based on servicepools with flexible resources. An automated tool for facilitatingmigration may include migration of services from a first architecture toappropriate service pools with flexible resources of a secondarchitecture. Prior to or during migration, the automated tool maydetermine that certain services available from a first website hostingarchitecture may be candidates for integrating within one or moreservice pools that may be adapted to provide flexible resources in asecond website hosting architecture. In an example, a virtual network isused during migration to facilitate keeping the network active duringthe movement of IP addresses from one architecture to another. To ensurethat all services are migrated to a second web hosting architecture, thetool may determine that at least one of the plurality of services of thefirst architecture may be made available to clients of the second webhosting architecture through one or more of the second architectureservice pools that themselves may be distributed across a plurality ofservers with each server adapted to provide an overlapping service setin order to facilitate flexible resources from each of the plurality ofservice pools. In some instances, the servers may be virtualized,physical or a combination of both.

Migration of web hosting services from a dedicated machine firstarchitecture to a cloud and/or grid based computing second architecturemay be associated with a website hosting service that is based on acommon service architecture and third party services. An automated toolfor facilitating migration may include migration of third partyservices. Prior to or during migration, the automated tool may determinethat certain services available from a first website hostingarchitecture may be candidates for third-party services in a secondwebsite hosting architecture. In an example, the first architecture maycomprise a server architecture that serves the services necessary for aspecific website or a plurality of distinct websites from a dedicatedmachine. Further, the dedicated machine of the first website hostingarchitecture may have one or more substantially duplicate machines forbackup purposes. To ensure that all services are migrated to a secondweb hosting architecture that may comprise a server architecture thatserves a plurality of common services from a plurality of machines to aplurality of [unrelated/unaffiliated] websites using a cloud and/or gridcomputing architecture, the tool may determine that at least one of theplurality of services may be available to clients of the second webhosting architecture through a third party[interface/API/plug-in/service] that allows the clients to experienceinformation consistent with a market specific service offering.

By identifying services to be migrated that are available as third-partyservices, the tool may allow a web hosting service to migrate andincorporate services that are native to the first web hostingarchitecture as well as third party services that are provided throughthe first web hosting architecture. In addition to identifying servicesin the first architecture that may be provided as third-party servicesin the second architecture, migration may result in third-party servicesprovided through the first architecture to be migrated to services thatare natively provided by the second architecture. This may provide amore highly integrated and smoother running web hosting experience forthe clients who are migrated from the first architecture to the secondarchitecture.

Migration of web hosting services from a dedicated machine firstarchitecture to a cloud and/or grid based computing second architecturemay be associated may be associated with a website hosting service thatis based on a common service architecture that supports multiplebranding and OSS consistency. An automated tool for facilitatingmigration may include migration of branding and operational supportservices. Prior to or during migration, the automated tool may determinethat certain branding capabilities or operational support servicesavailable from a first website hosting architecture may be candidatesfor integrating with multiple branding and operational support servicecapabilities of a second website hosting architecture. In an example,the first architecture may comprise a server architecture that servesthe services necessary for a specific website or a plurality of distinctwebsites from a dedicated machine. Further, the dedicated machine of thefirst website hosting architecture may have one or more substantiallyduplicate machines for backup purposes. To ensure that all services aremigrated to a second web hosting architecture that may comprise a serverarchitecture that serves a plurality of common services from a pluralityof machines to a plurality of [unrelated/unaffiliated] websites using acloud and/or grid computing architecture, the tool may determine that abrand of the first web hosting architecture may be suitable for beingmade available to clients and prospective clients of the second webhosting architecture through the multiple branding capability. The brandof the first web hosting architecture may be configured as a marketspecific offering of the second web hosting architecture wherein theoffering may be maintained under a consistent look and feel associatedwith the market specific offering when presenting account service userinterfaces. Such offerings may include different brands, messages,service terms and/or different pricing structures.

Migration of web hosting services from one architecture to another, suchas where at least one of the architectures is a one box per customer ormultiple customers that may be configured to many boxes per manycustomers using a grid and/or a cloud computing architecture, may beassociated with a website hosting service that is based on anunaffiliated web domain common hosting service architecture with one ormore service representative plug ins. An automated tool for facilitatingmigration may include migration of service representative plug-ins.Prior to or during migration, the automated tool may determine thatcertain services available from a first website hosting architecture maybe candidates for one or more service representative plug-ins in asecond website hosting architecture. In an example, the firstarchitecture may comprise a server architecture that serves the servicesnecessary for a specific website or a plurality of distinct websitesfrom a dedicated machine. Further, the dedicated machine of the firstwebsite hosting architecture may have one or more substantiallyduplicate machines for backup purposes. To ensure that all services aremigrated to a second web hosting architecture that may comprise a serverarchitecture that serves a plurality of common services from a pluralityof machines to a plurality of [unrelated/unaffiliated] websites using acloud and/or grid computing architecture, the tool may determine that atleast one of the plurality of services may be available to clients ofthe second web hosting architecture where the web hosting service may bemarketed through a plurality of websites offering a different marketspecific offering wherein service representatives may be provided thatsupport a plurality of different market specific offerings and suchrepresentatives may also be provided with information facilitatingproviding the appropriate service for a particular market specificoffering.

By identifying services to be migrated that are available as servicerepresentatives, the tool may allow a web hosting service to migrate andincorporate services that are native to the first web hostingarchitecture as well as third party services that are provided throughthe first web hosting architecture. In addition to identifying servicesin the first architecture that may be provided as servicerepresentatives in the second architecture, migration may result inservice representatives provided through the first architecture to bemigrated to services that are natively provided by the secondarchitecture. This may provide a more highly integrated and smootherrunning web hosting experience for the clients who are migrated from thefirst architecture to the second architecture.

Migration of web hosting services from one architecture to another, suchas where at least one of the architectures is a one box per customer ormultiple customers that may be configured to many boxes per manycustomers using a grid and/or a cloud computing architecture, may beassociated with an unaffiliated web domain hosting service that is basedon service pools with flexible resources. An automated tool forfacilitating migration may include migration of service pools that maybe adapted to provide flexible resources. Prior to or during migration,the automated tool may determine that certain services available from afirst website hosting architecture may be candidates for service poolsthat may be adapted to provide flexible resources in a second websitehosting architecture. In an example, the first architecture may comprisea server architecture that serves the services necessary for a specificwebsite or a plurality of distinct websites from a dedicated machine.Further, the dedicated machine of the first website hosting architecturemay have one or more substantially duplicate machines for backuppurposes. To ensure that all services are migrated to a second webhosting architecture that may comprise a server architecture that servesa plurality of common services from a plurality of machines to aplurality of [unrelated/unaffiliated] websites using a cloud and/or gridcomputing architecture, the tool may determine that at least one of aplurality of service pools may be available to clients of the second webhosting architecture where each of the plurality of service pools may beadapted to contribute services to distinct service packages and whereeach of the service pools may be distributed across a plurality ofservers adapted to provide an overlapping service set in order tofacilitate flexible resources from each of the plurality of servicepools. In some instances, the servers may be virtualized, physical or acombination of both.

By identifying services to be migrated that are available as servicepools with flexible resources, the tool may allow a web hosting serviceto migrate and incorporate services that are native to the first webhosting architecture as well as third party services that are providedthrough the first web hosting architecture. In addition to identifyingservices in the first architecture that may be provided as service poolswith flexible resources in the second architecture, migration may resultin service pools with flexible resources services provided through thefirst architecture to be migrated to services that are natively providedby the second architecture. This may provide a more highly integratedand smoother running web hosting experience for the clients who aremigrated from the first architecture to the second architecture.

Migration of web hosting services from one architecture to another, suchas where at least one of the architectures is a dedicated environmentfor each customer that may be configured to support a shared environmentfor multiple customers, may be associated with a website hosting servicethat is based on a common service architecture and third party services.An automated tool for facilitating migration may include migration ofthird party services. Prior to or during migration, the automated toolmay determine that certain services available from a first websitehosting architecture may be candidates for third-party services in asecond website hosting architecture. In an example, the firstarchitecture may comprise a virtualized or non-virtualized serverarchitecture that serves a plurality of common services from a pluralityof machines to a plurality of [unrelated/unaffiliated] websites and/orthat serves the services necessary for a customer's websites from adedicated machine and/or a specific virtual machine. To ensure that allservices are migrated to a second web hosting architecture that maycomprise a server architecture that serves a plurality of common oruncommon services to a plurality of [unrelated/unaffiliated] customersand/or websites from a plurality of shared servers and/or machines, thetool may determine that at least one of the plurality of services may beavailable to clients of the second web hosting architecture through athird party [interface/API/plug-in/service] that allows the clients toexperience information consistent with a market specific serviceoffering. Further, the dedicated environment or at least one environmentmay include dedicated memory for each customer wherein the sharedenvironment includes shared memory across multiple servers, and theshared environment may be a cloud or grid computing environment. Theshared environment or at least one environment may also include aplurality of common service pools disposed across a plurality ofservers.

By identifying services to be migrated that are available as third-partyservices, the tool may allow a web hosting service to migrate andincorporate services that are native to the first web hostingarchitecture as well as third party services that are provided throughthe first web hosting architecture. In addition to identifying servicesin the first architecture that may be provided as third-party servicesin the second architecture, migration may result in third-party servicesprovided through the first architecture to be migrated to services thatare natively provided by the second architecture. This may provide amore highly integrated and smoother running web hosting experience forthe clients who are migrated from the first architecture to the secondarchitecture.

Migration of web hosting services from one architecture to another, suchas where at least one of the architectures is a dedicated environmentfor each customer that may be configured to support a shared environmentfor multiple customers, may be associated with a website hosting servicethat is based on a common service architecture with multiple brandingand OSS consistency. An automated tool for facilitating migration mayinclude migration of branding and operational support services. Prior toor during migration, the automated tool may determine that certainservices available from a first website hosting architecture may becandidates for branding and operational support services in a secondwebsite hosting architecture. In an example, the first architecture maycomprise a virtualized or non-virtualized server architecture thatserves a plurality of common services from a plurality of machines to aplurality of [unrelated/unaffiliated] websites and/or that serves theservices necessary for a customer's websites from a dedicated machineand/or a specific virtual machine. To ensure that all services aremigrated to a second web hosting architecture that may comprise a serverarchitecture that serves a plurality of common or uncommon services to aplurality of [unrelated/unaffiliated] customers and/or websites from aplurality of shared servers and/or machines, the tool may determine thatat least one of the plurality of services may be available to clients ofthe second web hosting architecture and therefore offer a differentmarket specific offering wherein each offering may be maintained under aconsistent look and feel associated with the market specific offeringwhen presenting account service user interfaces. Such offerings mayinclude different brands, messages, service terms and/or differentpricing structures. Further, the dedicated environment or at least oneenvironment may include dedicated memory for each customer wherein theshared environment includes shared memory across multiple servers, andthe shared environment may be a cloud or grid computing environment. Theshared environment or at least one environment may also include aplurality of common service pools disposed across a plurality ofservers.

By identifying services to be migrated that are available as brandingand operational support services, the tool may allow a web hostingservice to migrate and incorporate services that are native to the firstweb hosting architecture as well as third party services that areprovided through the first web hosting architecture. In addition toidentifying services in the first architecture that may be provided asbranding and operational support services in the second architecture,migration may result in branding and operational support servicesprovided through the first architecture to be migrated to services thatare natively provided by the second architecture. This may provide amore highly integrated and smoother running web hosting experience forthe clients who are migrated from the first architecture to the secondarchitecture.

Migration of web hosting services from one architecture to another, suchas where at least one of the architectures is a dedicated environmentfor each customer that may be configured to support a shared environmentfor multiple customers, may be associated with a website hosting servicethat is based on an unaffiliated web domain common hosting servicearchitecture with one or more service representative plug ins. Anautomated tool for facilitating migration may include migration of oneor more service representative plug-ins. Prior to or during migration,the automated tool may determine that certain services available from afirst website hosting architecture may be candidates for one or moreservice representative plug-ins in a second website hostingarchitecture. In an example, the first architecture may comprise avirtualized or non-virtualized server architecture that serves aplurality of common services from a plurality of machines to a pluralityof [unrelated/unaffiliated] websites and/or that serves the servicesnecessary for a customer's websites from a dedicated machine and/or aspecific virtual machine. To ensure that all services are migrated to asecond web hosting architecture that may comprise a server architecturethat serves a plurality of common or uncommon services to a plurality of[unrelated/unaffiliated] customers and/or websites from a plurality ofshared servers and/or machines, the tool may determine that at least oneof the plurality of services may be available to clients of the secondweb hosting architecture where the web hosting service may be marketedthrough a plurality of websites offering a different market specificoffering wherein service representatives may be provided that support aplurality of different market specific offerings and suchrepresentatives may also be provided with information facilitatingproviding the appropriate service for a particular market specificoffering. Further, the dedicated environment or at least one environmentmay include dedicated memory for each customer wherein the sharedenvironment includes shared memory across multiple servers, and theshared environment may be a cloud or grid computing environment. Theshared environment or at least one environment may also include aplurality of common service pools disposed across a plurality ofservers.

By identifying services to be migrated that are available as servicerepresentatives, the tool may allow a web hosting service to migrate andincorporate services that are native to the first web hostingarchitecture as well as third party services that are provided throughthe first web hosting architecture. In addition to identifying servicesin the first architecture that may be provided as servicerepresentatives in the second architecture, migration may result inservice representatives provided through the first architecture to bemigrated to services that are natively provided by the secondarchitecture. This may provide a more highly integrated and smootherrunning web hosting experience for the clients who are migrated from thefirst architecture to the second architecture.

Migration of web hosting services from one architecture to another, suchas where at least one of the architectures is a dedicated environmentfor each customer that may be configured to support a shared environmentfor multiple customers, may be associated with an unaffiliated webdomain hosting service that is based on service pools with flexibleresources. An automated tool for facilitating migration may includemigration of service pools that may be adapted to provide flexibleresources. Prior to or during migration, the automated tool maydetermine that certain services available from a first website hostingarchitecture may be candidates for service pools that may be adapted toprovide flexible resources in a second website hosting architecture. Inan example, the first architecture may comprise a virtualized ornon-virtualized server architecture that serves a plurality of commonservices from a plurality of machines to a plurality of[unrelated/unaffiliated] websites and/or that serves the servicesnecessary for a customer's websites from a dedicated machine and/or aspecific virtual machine. To ensure that all services are migrated to asecond web hosting architecture that may comprise a server architecturethat serves a plurality of common or uncommon services to a plurality of[unrelated/unaffiliated] customers and/or websites from a plurality ofshared servers and/or machines, the tool may determine that at least oneof the plurality of service pools may be available to clients of thesecond web hosting architecture where each of the plurality of servicepools may be adapted to contribute services to distinct service packagesand where each of the service pools may be distributed across aplurality of servers adapted to provide an overlapping service set inorder to facilitate flexible resources from each of the plurality ofservice pools. In some instances, the servers may be virtualized,physical or a combination of both. Further, the dedicated environment orat least one environment may include dedicated memory for each customerwherein the shared environment includes shared memory across multipleservers, and the shared environment may be a cloud or grid computingenvironment. The shared environment or at least one environment may alsoinclude a plurality of common service pools disposed across a pluralityof servers.

By identifying services to be migrated that are available as servicepools with flexible resources, the tool may allow a web hosting serviceto migrate and incorporate services that are native to the first webhosting architecture as well as third party services that are providedthrough the first web hosting architecture. In addition to identifyingservices in the first architecture that may be provided as service poolswith flexible resources in the second architecture, migration may resultin service pools with flexible resources provided through the firstarchitecture to be migrated to services that are natively provided bythe second architecture. This may provide a more highly integrated andsmoother running web hosting experience for the clients who are migratedfrom the first architecture to the second architecture.

The methods and systems described herein may be deployed in part or inwhole through a machine that executes computer software, program codes,and/or instructions on a processor. The processor may be part of aserver, client, network infrastructure, mobile computing platform,stationary computing platform, or other computing platform. A processormay be any kind of computational or processing device capable ofexecuting program instructions, codes, binary instructions and the like.The processor may be or include a signal processor, digital processor,embedded processor, microprocessor or any variant such as a co-processor(math co-processor, graphic co-processor, communication co-processor andthe like) and the like that may directly or indirectly facilitateexecution of program code or program instructions stored thereon. Inaddition, the processor may enable execution of multiple programs,threads, and codes. The threads may be executed simultaneously toenhance the performance of the processor and to facilitate simultaneousoperations of the application. By way of implementation, methods,program codes, program instructions and the like described herein may beimplemented in one or more thread. The thread may spawn other threadsthat may have assigned priorities associated with them; the processormay execute these threads based on priority or any other order based oninstructions provided in the program code. The processor may includememory that stores methods, codes, instructions and programs asdescribed herein and elsewhere. The processor may access a storagemedium through an interface that may store methods, codes, andinstructions as described herein and elsewhere. The storage mediumassociated with the processor for storing methods, programs, codes,program instructions or other type of instructions capable of beingexecuted by the computing or processing device may include but may notbe limited to one or more of a CD-ROM, DVD, memory, hard disk, flashdrive, RAM, ROM, cache and the like.

A processor may include one or more cores that may enhance speed andperformance of a multiprocessor. In embodiments, the process may be adual core processor, quad core processors, other chip-levelmultiprocessor and the like that combine two or more independent cores(called a die).

The methods and systems described herein may be deployed in part or inwhole through a machine that executes computer software on a server,client, firewall, gateway, hub, router, or other such computer and/ornetworking hardware. The software program may be associated with aserver that may include a file server, print server, domain server,internet server, intranet server and other variants such as secondaryserver, host server, distributed server and the like. The server mayinclude one or more of memories, processors, computer readable media,storage media, ports (physical and virtual), communication devices, andinterfaces capable of accessing other servers, clients, machines, anddevices through a wired or a wireless medium, and the like. The methods,programs or codes as described herein and elsewhere may be executed bythe server. In addition, other devices required for execution of methodsas described in this application may be considered as a part of theinfrastructure associated with the server.

The server may provide an interface to other devices including, withoutlimitation, clients, other servers, printers, database servers, printservers, file servers, communication servers, distributed servers andthe like. Additionally, this coupling and/or connection may facilitateremote execution of program across the network. The networking of someor all of these devices may facilitate parallel processing of a programor method at one or more location without deviating from the scope ofthe invention. In addition, any of the devices attached to the serverthrough an interface may include at least one storage medium capable ofstoring methods, programs, code and/or instructions. A centralrepository may provide program instructions to be executed on differentdevices. In this implementation, the remote repository may act as astorage medium for program code, instructions, and programs.

The software program may be associated with a client that may include afile client, print client, domain client, internet client, intranetclient and other variants such as secondary client, host client,distributed client and the like. The client may include one or more ofmemories, processors, computer readable media, storage media, ports(physical and virtual), communication devices, and interfaces capable ofaccessing other clients, servers, machines, and devices through a wiredor a wireless medium, and the like. The methods, programs or codes asdescribed herein and elsewhere may be executed by the client. Inaddition, other devices required for execution of methods as describedin this application may be considered as a part of the infrastructureassociated with the client.

The client may provide an interface to other devices including, withoutlimitation, servers, other clients, printers, database servers, printservers, file servers, communication servers, distributed servers andthe like. Additionally, this coupling and/or connection may facilitateremote execution of program across the network. The networking of someor all of these devices may facilitate parallel processing of a programor method at one or more location without deviating from the scope ofthe invention. In addition, any of the devices attached to the clientthrough an interface may include at least one storage medium capable ofstoring methods, programs, applications, code and/or instructions. Acentral repository may provide program instructions to be executed ondifferent devices. In this implementation, the remote repository may actas a storage medium for program code, instructions, and programs.

The methods and systems described herein may be deployed in part or inwhole through network infrastructures. The network infrastructure mayinclude elements such as computing devices, servers, routers, hubs,firewalls, clients, personal computers, communication devices, routingdevices and other active and passive devices, modules and/or componentsas known in the art. The computing and/or non-computing device(s)associated with the network infrastructure may include, apart from othercomponents, a storage medium such as flash memory, buffer, stack, RAM,ROM and the like. The processes, methods, program codes, instructionsdescribed herein and elsewhere may be executed by one or more of thenetwork infrastructural elements.

The methods, program codes, and instructions described herein andelsewhere may be implemented on a cellular network having multiplecells. The cellular network may either be frequency division multipleaccess (FDMA) network or code division multiple access (CDMA) network.The cellular network may include mobile devices, cell sites, basestations, repeaters, antennas, towers, and the like. The cell networkmay be a GSM, GPRS, 3G, EVDO, mesh, or other networks types.

The methods, programs codes, and instructions described herein andelsewhere may be implemented on or through mobile devices. The mobiledevices may include navigation devices, cell phones, mobile phones,mobile personal digital assistants, laptops, palmtops, netbooks, pagers,electronic books readers, music players and the like. These devices mayinclude, apart from other components, a storage medium such as a flashmemory, buffer, RAM, ROM and one or more computing devices. Thecomputing devices associated with mobile devices may be enabled toexecute program codes, methods, and instructions stored thereon.Alternatively, the mobile devices may be configured to executeinstructions in collaboration with other devices. The mobile devices maycommunicate with base stations interfaced with servers and configured toexecute program codes. The mobile devices may communicate on a peer topeer network, mesh network, or other communications network. The programcode may be stored on the storage medium associated with the server andexecuted by a computing device embedded within the server. The basestation may include a computing device and a storage medium. The storagedevice may store program codes and instructions executed by thecomputing devices associated with the base station.

The computer software, program codes, and/or instructions may be storedand/or accessed on machine readable media that may include: computercomponents, devices, and recording media that retain digital data usedfor computing for some interval of time; semiconductor storage known asrandom access memory (RAM); mass storage typically for more permanentstorage, such as optical discs, forms of magnetic storage like harddisks, tapes, drums, cards and other types; processor registers, cachememory, volatile memory, non-volatile memory; optical storage such asCD, DVD; removable media such as flash memory (e.g. USB sticks or keys),floppy disks, magnetic tape, paper tape, punch cards, standalone RAMdisks, Zip drives, removable mass storage, off-line, and the like; othercomputer memory such as dynamic memory, static memory, read/writestorage, mutable storage, read only, random access, sequential access,location addressable, file addressable, content addressable, networkattached storage, storage area network, bar codes, magnetic ink, and thelike.

The methods and systems described herein may transform physical and/oror intangible items from one state to another. The methods and systemsdescribed herein may also transform data representing physical and/orintangible items from one state to another.

The elements described and depicted herein, including in flow charts andblock diagrams throughout the figures, imply logical boundaries betweenthe elements. However, according to software or hardware engineeringpractices, the depicted elements and the functions thereof may beimplemented on machines through computer executable media having aprocessor capable of executing program instructions stored thereon as amonolithic software structure, as standalone software modules, or asmodules that employ external routines, code, services, and so forth, orany combination of these, and all such implementations may be within thescope of the present disclosure. Examples of such machines may include,but may not be limited to, personal digital assistants, laptops,personal computers, mobile phones, other handheld computing devices,medical equipment, wired or wireless communication devices, transducers,chips, calculators, satellites, tablet PCs, electronic books, gadgets,electronic devices, devices having artificial intelligence, computingdevices, networking equipment, servers, routers and the like.Furthermore, the elements depicted in the flow chart and block diagramsor any other logical component may be implemented on a machine capableof executing program instructions. Thus, while the foregoing drawingsand descriptions set forth functional aspects of the disclosed systems,no particular arrangement of software for implementing these functionalaspects should be inferred from these descriptions unless explicitlystated or otherwise clear from the context. Similarly, it will beappreciated that the various steps identified and described above may bevaried, and that the order of steps may be adapted to particularapplications of the techniques disclosed herein. All such variations andmodifications are intended to fall within the scope of this disclosure.As such, the depiction and/or description of an order for various stepsshould not be understood to require a particular order of execution forthose steps, unless required by a particular application, or explicitlystated or otherwise clear from the context.

The methods and/or processes described above, and steps thereof, may berealized in hardware, software or any combination of hardware andsoftware suitable for a particular application. The hardware may includea general purpose computer and/or dedicated computing device or specificcomputing device or particular aspect or component of a specificcomputing device. The processes may be realized in one or moremicroprocessors, microcontrollers, embedded microcontrollers,programmable digital signal processors or other programmable device,along with internal and/or external memory. The processes may also, orinstead, be embodied in an application specific integrated circuit, aprogrammable gate array, programmable array logic, or any other deviceor combination of devices that may be configured to process electronicsignals. It will further be appreciated that one or more of theprocesses may be realized as a computer executable code capable of beingexecuted on a machine readable medium.

The computer executable code may be created using a structuredprogramming language such as C, an object oriented programming languagesuch as C++, or any other high-level or low-level programming language(including assembly languages, hardware description languages, anddatabase programming languages and technologies) that may be stored,compiled or interpreted to run on one of the above devices, as well asheterogeneous combinations of processors, processor architectures, orcombinations of different hardware and software, or any other machinecapable of executing program instructions.

Thus, in one aspect, each method described above and combinationsthereof may be embodied in computer executable code that, when executingon one or more computing devices, performs the steps thereof. In anotheraspect, the methods may be embodied in systems that perform the stepsthereof, and may be distributed across devices in a number of ways, orall of the functionality may be integrated into a dedicated, standalonedevice or other hardware. In another aspect, the means for performingthe steps associated with the processes described above may include anyof the hardware and/or software described above. All such permutationsand combinations are intended to fall within the scope of the presentdisclosure.

While the invention has been disclosed in connection with the preferredembodiments shown and described in detail, various modifications andimprovements thereon will become readily apparent to those skilled inthe art. Accordingly, the spirit and scope of the present invention isnot to be limited by the foregoing examples, but is to be understood inthe broadest sense allowable by law.

All documents referenced herein are hereby incorporated by reference.

1. A method of automatic website hosting service migration, comprising:determining a plurality of first common website hosting servicesprovided by a first website hosting architecture that serves a pluralityof common services from a plurality of machines to a plurality ofunrelated websites; analyzing the plurality of first common websitehosting services to identify at least one of the plurality of firstcommon website hosting services that corresponds to a common websitehosting service of a second website hosting architecture; and inresponse to a request for the at least one of the plurality of firstcommon website hosting services, serving the corresponding commonwebsite hosting service from the second website hosting architecture,wherein the second website hosting architecture serves a plurality ofcommon website hosting services from a plurality of machines to aplurality of unrelated websites.
 2. The method of claim 1, wherein thesecond web site hosting architecture is a cloud computing environment.3. The method of claim 1, wherein the second web site hostingarchitecture is a grid computing environment.
 4. The method of claim 1,wherein the plurality of machines of the second website hostingarchitecture is configured into a plurality of common service pools. 5.The method of claim 1, wherein the first web site hosting architectureis a cloud computing environment.
 6. The method of claim 1, wherein thefirst website hosting architecture is a grid computing environment. 7.The method of claim 1, wherein the plurality of machines of the firstweb site hosting architecture is configured into a plurality of commonservice pools.
 8. The method of claim 1, wherein the first web sitehosting architecture is one of a grid and a cloud computing environmentand the second website hosting architecture is one of a grid and a cloudcomputing environment.
 9. The method of claim 1, wherein the pluralityof machines of each of the first and second website hostingarchitectures are configured into a plurality of common service pools.10. The method of claim 1, wherein serving the corresponding commonwebsite hosting service includes determining a migration status for theat least one of the plurality of first common website hosting servicesand serving one of the at least one of the plurality of first commonwebsite hosting services from the first website hosting architecture andthe corresponding common website hosting service from the second websitehosting architecture based on the determination.
 11. The method of claim1, wherein the first web site hosting architecture comprises a virtualcomputing environment.
 12. The method of claim 1, wherein the secondwebsite hosting architecture comprises a virtual computing environment.